Azure Developer CLI | The .NET Blog

Hooks azd en Python, TypeScript et .NET : fini les scripts shell

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

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

Vous avez déjà eu un projet entièrement en .NET et vous avez quand même dû écrire des scripts Bash pour les hooks azd ? Vous connaissez la douleur. Pourquoi basculer vers la syntaxe shell pour une étape de pré-provisioning quand tout le reste du projet est en C# ?

Cette frustration a maintenant une solution officielle. La CLI Azure Developer vient de publier la prise en charge multi-langages pour les hooks, et c’est exactement aussi bien que ça en a l’air.

Les hooks, en bref

Les hooks sont des scripts qui s’exécutent à des moments clés du cycle de vie d’azd — avant le provisioning, après le déploiement, etc. Définis dans azure.yaml, ils permettent d’injecter de la logique personnalisée sans modifier la CLI.

Avant, seuls Bash et PowerShell étaient supportés. Maintenant, on peut utiliser Python, JavaScript, TypeScript ou .NET — et azd s’occupe du reste automatiquement.

Comment fonctionne la détection

Il suffit de pointer le hook vers un fichier et azd déduit le langage à partir de l’extension :

hooks:
 preprovision:
 run: ./hooks/setup.py
 postdeploy:
 run: ./hooks/seed.ts
 postprovision:
 run: ./hooks/migrate.cs

Pas de configuration supplémentaire. Si l’extension est ambiguë, on peut ajouter kind: python (ou le langage correspondant) pour le préciser.

Détails par langage

Python

Placer un requirements.txt ou pyproject.toml à côté du script (ou dans un répertoire parent). azd crée automatiquement un environnement virtuel, installe les dépendances et exécute le script.

JavaScript et TypeScript

Même principe — un package.json près du script, et azd exécute d’abord npm install. Pour TypeScript, il utilise npx tsx sans étape de compilation et sans tsconfig.json.

.NET

Deux modes disponibles :

Mode projet : Si un .csproj est présent à côté du script, azd exécute automatiquement dotnet restore et dotnet build.
Mode single-file : Sur .NET 10+, les fichiers .cs autonomes s’exécutent directement via dotnet run script.cs. Aucun fichier de projet requis.

Configuration par exécuteur

Chaque langage supporte un bloc config optionnel :

hooks:
 preprovision:
 run: ./hooks/setup.ts
 config:
 packageManager: pnpm
 postprovision:
 run: ./hooks/migrate.cs
 config:
 configuration: Release
 framework: net10.0

Pourquoi c’est important pour les développeurs .NET

Les hooks étaient le dernier endroit dans un projet azd qui forçait à changer de langage. Maintenant, l’intégralité du pipeline de déploiement peut vivre dans un seul langage. Il devient possible de réutiliser les utilitaires .NET existants dans les hooks, de référencer des bibliothèques partagées et d’abandonner la maintenance de scripts shell.

Conclusion

Un de ces changements qui paraissent anodins mais qui réduisent concrètement la friction au quotidien avec azd. Le support multi-langages pour les hooks est disponible maintenant — tous les détails dans le post officiel.

azd + GitHub Copilot : Configuration de projet assistée par IA et résolution intelligente des erreurs

Emiliano Montesdeoca — Tue, 21 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale en anglais, clique ici.

Tu connais ce moment où tu veux déployer une app existante sur Azure et tu te retrouves à fixer un azure.yaml vide, en essayant de te rappeler si ton API Express devrait utiliser Container Apps ou App Service ? Ce moment vient de devenir beaucoup plus court.

L’Azure Developer CLI (azd) s’intègre maintenant avec GitHub Copilot de deux façons concrètes : scaffolding assisté par IA pendant azd init, et résolution intelligente des erreurs quand les déploiements échouent. Les deux fonctionnalités restent entièrement dans ton terminal — exactement là où je veux qu’elles soient.

Configuration avec Copilot pendant azd init

Quand tu lances azd init, il y a maintenant une option “Set up with GitHub Copilot (Preview)”. Sélectionne-la et Copilot analyse ta base de code pour générer l’azure.yaml, les templates d’infrastructure et les modules Bicep — basés sur ton code réel.

azd init
# Sélectionne : "Set up with GitHub Copilot (Preview)"

Prérequis :

azd 1.23.11 ou supérieur — vérifie avec azd version ou mets à jour avec azd update
Un abonnement GitHub Copilot actif (Individual, Business ou Enterprise)
GitHub CLI (gh) — azd demandera la connexion si nécessaire

Ce que je trouve vraiment utile : ça fonctionne dans les deux sens. Tu construis depuis zéro ? Copilot t’aide à configurer les bons services Azure dès le départ. Tu as une app existante que tu voulais déployer depuis longtemps ? Pointe Copilot dessus et il génère la configuration sans que tu aies à restructurer quoi que ce soit.

Ce que ça fait concrètement

Imaginons une API Express Node.js avec une dépendance PostgreSQL. Au lieu de décider manuellement entre Container Apps et App Service, puis d’écrire du Bicep depuis zéro, Copilot détecte ton stack et génère :

Un azure.yaml avec les bons paramètres language, host et build
Un module Bicep pour Azure Container Apps
Un module Bicep pour Azure Database for PostgreSQL

Et il effectue des vérifications préalables avant de toucher quoi que ce soit — vérifie que ton répertoire git est propre, demande le consentement pour les outils du serveur MCP. Rien ne se passe sans que tu saches exactement ce qui va changer.

Résolution d’erreurs avec Copilot

Les erreurs de déploiement, ça arrive. Paramètres manquants, problèmes de permissions, disponibilité des SKUs — et le message d’erreur ne te dit rarement la seule chose dont tu as vraiment besoin : comment régler le problème.

Sans Copilot, la boucle ressemble à : copier l’erreur → chercher dans la doc → lire trois réponses Stack Overflow hors sujet → exécuter quelques commandes az CLI → réessayer en espérant que ça marche. Avec Copilot intégré dans azd, cette boucle s’effondre. Quand une commande azd échoue, elle propose immédiatement quatre options :

Explain — explication en langage naturel de ce qui s’est passé
Guidance — instructions étape par étape pour corriger le problème
Diagnose and Guide — analyse complète + Copilot applique le correctif (avec ton approbation) + nouvelle tentative optionnelle
Skip — gérer toi-même

L’essentiel : Copilot a déjà le contexte de ton projet, la commande qui a échoué et les détails de l’erreur. Ses suggestions sont spécifiques à ta situation, pas de la documentation générique.

Configurer un comportement par défaut

Si tu choisis toujours la même option, saute le prompt interactif :

azd config set copilot.errorHandling.category troubleshoot

Valeurs : explain, guidance, troubleshoot, fix, skip. Tu peux aussi activer l’auto-fix et le retry :

azd config set copilot.errorHandling.fix allow

Retour au mode interactif à tout moment :

azd config unset copilot.errorHandling.category

Conclusion

C’est exactement le type d’intégration Copilot qui apporte une vraie valeur. Essaie-le en lançant azd update pour obtenir la dernière version, puis utilise azd init sur ton prochain projet.

Lis l’annonce originale ici.