Aspire | The .NET Blog

Endpoints Privés, VNets, NSGs — Aspire Gère le Réseau Maintenant

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

J’ai vu ce scénario trop de fois. L’application est terminée. La démo est excellente. Puis la liste de contrôle de sécurité arrive : sortir le stockage d’internet public, s’exécuter dans un VNet, fournir des IPs sortantes pour la liste d’autorisation du partenaire, prouver que seuls les bons sous-réseaux parlent aux bons services.

À ce stade, le modèle d’application et le modèle d’infrastructure commencent à diverger de manières douloureuses à maintenir.

Le nouveau support réseau d’entreprise Azure pour Aspire répond directement à cela. Vous décrivez la forme du réseau à côté des ressources qui l’utilisent, dans votre AppHost.

Les Blocs de Construction

Voici à quoi sert chaque concept réseau Azure, résumé :

Fonctionnalité	Utilisez-le quand	Pourquoi c’est important
Réseau virtuel	Vous avez besoin d’un espace d’adressage privé	La limite réseau pour les sous-réseaux, les endpoints privés et le routage
Sous-réseau	Vous devez séparer les charges de travail dans le VNet	Chaque partie du système obtient sa propre plage d’adresses et surface de politique
Sous-réseau délégué	Un service de plateforme (comme ACA) doit gérer un sous-réseau	Permet au service de placer une infrastructure gérée dans votre VNet en toute sécurité
Passerelle NAT	Vous avez besoin d’IPs publiques sortantes prévisibles	Adresse stable pour les listes d’autorisation et l’audit
Endpoint privé	Vous voulez une ressource PaaS accessible privément	Place une IP privée pour ce service dans votre VNet, supprime l’exposition publique
NSG	Vous avez besoin de règles de trafic au niveau du sous-réseau	Autoriser/refuser explicitement pour le trafic entrant et sortant par sous-réseau

Le Décrire dans votre AppHost

Le changement clé ici est que vous modélisez le réseau aux côtés des ressources qui l’utilisent, pas dans un fichier Bicep séparé qui dérive du modèle d’application avec le temps.

Depuis l’AppHost, vous pouvez :

Créer des VNets et des sous-réseaux avec AddVirtualNetwork() et AddSubnet()
Attacher une passerelle NAT aux sous-réseaux pour des IPs sortantes stables
Créer des endpoints privés pour le stockage, Key Vault, SQL et d’autres services PaaS
Définir des NSG avec des règles de sécurité entrantes et sortantes
Configurer des Périmètres de Sécurité Réseau pour des politiques inter-ressources

Le résultat est que lorsque vous exécutez azd up, l’infrastructure correspond à ce que le modèle d’application dit qu’il a besoin. Pas ce que dit un modèle maintenu manuellement.

Pourquoi C’est Important pour les Applications Réelles

Quelques choses qui deviennent significativement plus faciles une fois que le réseau est modélisé dans Aspire :

Endpoints privés pour Key Vault et stockage — vous décrivez WithPrivateEndpoint() sur ces ressources, et Aspire gère la configuration des zones DNS et l’attachement des endpoints. L’application ne change jamais.

IPs sortantes cohérentes — ajoutez une passerelle NAT au sous-réseau concerné et chaque requête sortante de votre application passe par une IP connue et stable. Les partenaires peuvent l’autoriser. Les auditeurs peuvent la tracer.

Règles NSG depuis le code — au lieu de cliquer dans le portail ou de maintenir un extrait Bicep, vos règles de sécurité vivent dans l’AppHost aux côtés des ressources qu’elles protègent.

C’est le type d’intégration qui ne rend pas les démos excitantes mais rend les systèmes de production maintenables.

Conclusion

La sécurité réseau apparaissant tard dans le cycle de vie du projet est un problème résolu si vous la modélisez aux côtés de l’application dès le début. Le support réseau d’entreprise d’Aspire rend cela possible sans nécessiter une piste d’infrastructure séparée.

Détails complets dans l’article original : Securing Azure apps with Aspire enterprise networking

Aspire 13.3 : Support Kubernetes, Journaux du Navigateur et la Compétence Aspireify

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

Cinq semaines, ce n’est pas beaucoup pour une version, mais Aspire 13.3 ne le semble pas. Les éléments principaux sont significatifs : déploiement Kubernetes et AKS de première classe avec Helm, une compétence d’intégration assistée par agent appelée Aspireify, la capture des journaux du navigateur directement dans le dashboard et des résultats de commandes structurés. En plus, 45 nouvelles fonctionnalités, 134 améliorations et 93 corrections de bugs.

Passons aux points saillants.

Aspireify : Intégration Assistée par Agent

Ajouter Aspire à un projet existant semble simple — ajoutez un AppHost, c’est fait. En pratique, cela implique beaucoup d’archéologie : quels ports comptent, quelles variables d’environnement sont de vraies dépendances, quels services Docker Compose doivent correspondre aux intégrations Aspire.

La nouvelle compétence Aspireify donne à votre agent de code un flux de travail guidé précisément pour cela. Quand aspire init crée un AppHost squelette, la compétence Aspireify aide l’agent à inspecter le dépôt, à comprendre comment il fonctionne déjà et à câbler l’AppHost pour s’adapter à l’application — pas l’inverse.

La posture par défaut est “minimiser les modifications de votre code.” Si votre application lit déjà DATABASE_URL, l’agent le mappe avec WithEnvironment() au lieu de vous demander de réécrire votre configuration. Si un port est codé en dur, la compétence indique à l’agent quand le préserver.

C’est le type d’outillage IA qui fait réellement gagner du temps plutôt que de générer plus de travail à revoir.

Déploiement Kubernetes et AKS de Première Classe

Celui-là était sur la liste de souhaits depuis un moment. Aspire 13.3 inclut le support de déploiement Kubernetes et AKS de première classe avec Helm. Vous pouvez maintenant cibler AKS comme destination de déploiement directement depuis les outils Aspire.

Pour les équipes qui exécutent déjà des charges de travail de production sur AKS, cela comble un écart significatif. Votre modèle d’application Aspire a maintenant un chemin propre du développement local vers Kubernetes sans rédaction manuelle de charts Helm.

Journaux du Navigateur dans le Dashboard

C’est une de ces fonctionnalités qui semblent mineures jusqu’à ce que vous déboguiez un problème frontend.

La nouvelle API WithBrowserLogs() attache une ressource de navigateur suivie à toute ressource capable d’endpoints. Aspire lance Chromium en utilisant un pipe CDP privé et diffuse les journaux de console, les requêtes réseau et les erreurs directement dans le flux de journaux de la ressource :

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

L’AppHost TypeScript prend en charge la même chose :

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

Erreurs de console, requêtes réseau échouées, exceptions côté client — tout visible dans le même dashboard où vous regardez déjà les traces et métriques. Plus besoin de changer d’onglet vers les DevTools du navigateur pour les bases.

Résultats de Commandes Structurés

Les commandes de ressources ont reçu une mise à niveau significative. Jusqu’à présent, les commandes renvoyaient succès/échec. Maintenant elles retournent des résultats structurés : texte, JSON ou markdown qui circule à travers le modèle, l’interface du dashboard, la CLI et les outils MCP.

Le dashboard relie tout cela avec un nouveau centre de notifications dans l’en-tête. Les résultats des commandes apparaissent sous forme de notifications horodatées avec rendu markdown et une action “Voir la réponse”.

Cela rend les commandes de ressources véritablement composables. Une intégration peut maintenant exposer une commande qui renvoie une sortie significative — comme une URL de tunnel — plutôt que de simplement changer d’état quelque part.

En Résumé

Aspire 13.3 vaut la mise à jour ne serait-ce que pour le support Kubernetes. Les journaux du navigateur et les résultats de commandes structurés ressemblent au type d’améliorations de qualité de vie qui s’accumulent rapidement dans un flux de travail de développement quotidien.

Notes de version complètes : What’s New in Aspire 13.3

Aspire 13.2 : Support Bun, Meilleurs Conteneurs et Moins de Friction de Debug

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

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

Si vous construisez des backends .NET avec des frontends JavaScript dans Aspire, la 13.2 est la mise à jour qui améliore silencieusement votre quotidien. Des améliorations solides à des choses légèrement agaçantes.

Bun est Maintenant Citoyen de Première Classe

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

Si votre équipe utilise déjà Bun, Aspire ne vous force plus à aller à contre-courant.

Yarn Plus Fiable

Les utilisateurs de Yarn bénéficient de moins d’échecs mystérieux avec withYarn() et addViteApp().

Améliorations des Conteneurs

Pull policy explicite avec ImagePullPolicy.Never pour utiliser l’image locale sans aller au registry. PostgreSQL 18+ avec des volumes de données fonctionne maintenant correctement.

Améliorations du Débogage

DebuggerDisplayAttribute sur les types core
Meilleurs messages d’erreur pour WaitFor
BeforeResourceStartedEvent se déclenche au bon moment

Conclusion

Post original de David Pine : Aspire 13.2: Bun Support and Container Enhancements.

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 a lieu le 18 avril 2026 au Kinépolis Diversia à Alcobendas, Madrid. C’est le plus grand événement communautaire Azure en Espagne, réunissant 38 speakers sur 3 tracks parallèles couvrant les agents IA, le réseau Azure, Cosmos DB, Fabric, IoT, la sécurité et bien plus.

L’événement se déroule de 08h30 à 18h30 et comprend une keynote, des pauses café, un déjeuner et une session de clôture Q&A.

Points forts de l’agenda

Domando Agentes de IA : gouvernance, outils et APIs avec Azure AI Foundry et Azure API Management
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis! : systèmes multi-agents en action
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

Billets

L’inscription est une donation symbolique — le prix du billet est entièrement reversé à Plan International, soutenant les droits des enfants et l’égalité dans le monde. Capacité limitée, alors réservez votre place rapidement.

Azure Tour 2026

Au-delà de Madrid, le Global Azure Tour 2026 comprend également des étapes à Saragosse, Tenerife et Séville.

Arrêtez de surveiller votre terminal : le mode détaché d'Aspire change la donne

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

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

À chaque fois que vous lancez un AppHost Aspire, votre terminal disparaît. Verrouillé. Occupé jusqu’à ce que vous fassiez Ctrl+C. Besoin d’exécuter une commande rapide ? Ouvrez un autre onglet. Envie de vérifier les logs ? Encore un onglet. C’est une petite friction qui s’accumule vite.

Aspire 13.2 corrige ça. James Newton-King a détaillé tout ça, et honnêtement, c’est une de ces fonctionnalités qui change immédiatement votre façon de travailler.

Mode détaché : une commande, terminal récupéré

aspire start

C’est le raccourci pour aspire run --detach. Votre AppHost démarre en arrière-plan et vous récupérez votre terminal immédiatement. Pas d’onglets supplémentaires. Pas de multiplexeur de terminal. Juste votre prompt, prêt à l’emploi.

Gérer ce qui tourne

Le truc, c’est que tourner en arrière-plan n’est utile que si on peut gérer ce qui s’y passe. Aspire 13.2 fournit un ensemble complet de commandes CLI pour exactement ça :

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

Ça transforme le CLI d’Aspire en un véritable gestionnaire de processus. Vous pouvez démarrer plusieurs AppHosts, vérifier leur statut, suivre leurs logs et les arrêter — le tout depuis une seule session de terminal.

Combinez-le avec le mode isolé

Le mode détaché se marie naturellement avec le mode isolé. Vous voulez lancer deux instances du même projet en arrière-plan sans conflits de ports ?

aspire start --isolated
aspire start --isolated

Chacune obtient des ports aléatoires, des secrets séparés et son propre cycle de vie. Utilisez aspire ps pour voir les deux, aspire stop pour arrêter celle dont vous n’avez plus besoin.

Pourquoi c’est énorme pour les agents de code

C’est là que ça devient vraiment intéressant. Un agent de code travaillant dans votre terminal peut maintenant :

Démarrer l’app avec aspire start
Interroger son état avec aspire describe
Vérifier les logs avec aspire logs pour diagnostiquer les problèmes
L’arrêter avec aspire stop quand il a terminé

Tout ça sans perdre la session de terminal. Avant le mode détaché, un agent qui lançait votre AppHost se retrouvait bloqué dans son propre terminal. Maintenant il peut démarrer, observer, itérer et nettoyer — exactement comme on voudrait qu’un agent autonome fonctionne.

L’équipe Aspire a misé là-dessus. Lancer aspire agent init met en place un fichier de compétences Aspire qui enseigne ces commandes aux agents. Ainsi, des outils comme l’agent de code de Copilot peuvent gérer vos workloads Aspire directement.

Pour conclure

Le mode détaché est une amélioration du workflow déguisée en simple flag. Vous arrêtez de jongler entre les terminaux, les agents ne se bloquent plus eux-mêmes, et les nouvelles commandes CLI vous donnent une vraie visibilité sur ce qui tourne. C’est pratique, c’est propre, et ça rend le cycle de développement quotidien nettement plus fluide.

Lisez le post complet pour tous les détails et récupérez Aspire 13.2 avec aspire update --self.

.NET Aspire 13.2 Veut Devenir le Meilleur Ami de Votre Agent IA

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

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

Tu connais ce moment où ton agent IA écrit du code solide, tu es tout excité, et puis tout s’effondre quand il essaie de lancer le truc ? Conflits de ports, processus fantômes, mauvaises variables d’environnement — soudain ton agent brûle des tokens à déboguer des problèmes de démarrage au lieu de construire des fonctionnalités.

L’équipe Aspire vient de publier un post très bien pensé sur exactement ce problème, et leur réponse est convaincante : Aspire 13.2 est conçu non seulement pour les humains, mais pour les agents IA.

Le problème est réel

Les agents IA sont incroyables pour écrire du code. Mais livrer une app full-stack fonctionnelle implique bien plus que générer des fichiers. Il faut démarrer les services dans le bon ordre, gérer les ports, configurer les variables d’environnement, connecter les bases de données et obtenir du feedback quand ça casse. Actuellement, la plupart des agents gèrent tout ça par essai-erreur — exécuter des commandes, lire les sorties d’erreur, réessayer.

On empile des instructions Markdown, des skills personnalisés et des prompts pour les guider, mais c’est imprévisible, ça ne se compile pas, et ça coûte des tokens juste pour parser. L’équipe Aspire a mis le doigt sur l’insight clé : les agents ont besoin de compilateurs et d’APIs structurées, pas de plus de Markdown.

Aspire comme infrastructure pour agents

Voici ce qu’Aspire 13.2 apporte à la table du développement agentique :

Toute ta stack en code typé. L’AppHost définit ta topologie complète — API, frontend, base de données, cache — en TypeScript ou C# compilable :

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

Un agent peut lire ça pour comprendre la topologie de l’app, ajouter des ressources, câbler les connexions et compiler pour vérifier. Le compilateur lui dit immédiatement si quelque chose ne va pas. Pas de devinettes, pas d’essai-erreur avec les fichiers de config.

Une seule commande pour les gouverner toutes. Au lieu que les agents jonglent entre docker compose up, npm run dev et les scripts de démarrage de base de données, tout est simplement aspire start. Toutes les ressources se lancent dans le bon ordre, sur les bons ports, avec la bonne configuration. Les processus longs ne bloquent pas non plus l’agent — Aspire les gère.

Mode isolé pour les agents parallèles. Avec --isolated, chaque exécution d’Aspire obtient ses propres ports aléatoires et secrets utilisateur séparés. Plusieurs agents travaillent sur des git worktrees ? Ils n’entreront pas en collision. C’est énorme pour des outils comme les agents en arrière-plan de VS Code qui créent des environnements parallèles.

Des yeux d’agent grâce à la télémétrie. C’est là que ça devient vraiment puissant. La CLI Aspire expose des données OpenTelemetry complètes pendant le développement — traces, métriques, logs structurés. Ton agent ne se contente pas de lire la sortie console en espérant que tout va bien. Il peut tracer une requête échouée à travers les services, profiler les endpoints lents et identifier précisément où les choses cassent. C’est de l’observabilité de niveau production dans la boucle de développement.

L’analogie des bumpers de bowling

L’équipe Aspire utilise une super analogie : pense à Aspire comme les bumpers de piste de bowling pour les agents IA. Si l’agent n’est pas parfait (et il ne le sera pas), les bumpers l’empêchent de faire des gouttières. La définition de la stack empêche les mauvaises configurations, le compilateur attrape les erreurs, la CLI gère les processus, et la télémétrie fournit la boucle de feedback.

Combine ça avec quelque chose comme Playwright CLI, et ton agent peut réellement utiliser ton app — cliquer dans les flux, vérifier le DOM, voir les trucs cassés dans la télémétrie, corriger le code, redémarrer et retester. Construire, exécuter, observer, corriger. C’est la boucle de développement autonome que nous poursuivons.

Pour démarrer

Nouveau avec Aspire ? Installe la CLI depuis get.aspire.dev et suis le guide de démarrage.

Tu utilises déjà Aspire ? Lance aspire update --self pour obtenir la 13.2, puis pointe ton agent de coding favori vers ton repo. Tu seras surpris de voir jusqu’où il ira avec les garde-fous d’Aspire.

Pour conclure

Aspire 13.2 n’est plus seulement un framework d’applications distribuées — il devient une infrastructure essentielle pour les agents. Des définitions de stack structurées, un démarrage en une commande, des exécutions parallèles isolées et de la télémétrie en temps réel donnent aux agents IA exactement ce dont ils ont besoin pour passer de l’écriture de code à la livraison d’apps.

Lis le post complet de l’équipe Aspire pour tous les détails et vidéos de démo.

Le Mode Isolé d'Aspire Résout le Cauchemar des Conflits de Ports pour le Développement Parallèle

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

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

Si tu as déjà essayé d’exécuter deux instances du même projet en même temps, tu connais la douleur. Le port 8080 est déjà utilisé. Le port 17370 est pris. Tuer quelque chose, redémarrer, jongler avec les variables d’environnement — c’est un tueur de productivité.

Ce problème empire, il ne s’améliore pas. Les agents IA créent des git worktrees pour travailler indépendamment. Les agents en arrière-plan démarrent des environnements séparés. Les développeurs font des checkout du même repo deux fois pour des branches de fonctionnalités. Chacun de ces scénarios frappe le même mur : deux instances de la même app qui se battent pour les mêmes ports.

Aspire 13.2 résout ça avec un seul flag. James Newton-King de l’équipe Aspire a écrit tous les détails, et c’est une de ces fonctionnalités « pourquoi on n’avait pas ça avant ? ».

La solution : `--isolated`

aspire run --isolated

C’est tout. Chaque exécution obtient :

Des ports aléatoires — plus de collisions entre instances
Des secrets utilisateur isolés — les chaînes de connexion et clés API restent séparées par instance

Pas de réattribution manuelle de ports. Pas de jonglage avec les variables d’environnement. Chaque exécution obtient un environnement propre et sans collision automatiquement.

Scénarios réels où ça brille

Checkouts multiples. Tu as une branche de fonctionnalité dans un répertoire et un bugfix dans un autre :

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

Les deux tournent sans conflit. Le dashboard montre ce qui tourne et où.

Agents en arrière-plan dans VS Code. Quand l’agent en arrière-plan de Copilot Chat crée un git worktree pour travailler sur ton code indépendamment, il peut avoir besoin d’exécuter ton AppHost Aspire. Sans --isolated, c’est un conflit de ports avec ton worktree principal. Avec, les deux instances fonctionnent tout simplement.

Le skill Aspire livré avec aspire agent init instruit automatiquement les agents d’utiliser --isolated quand ils travaillent dans des worktrees. Donc l’agent en arrière-plan de Copilot devrait gérer ça nativement.

Tests d’intégration en parallèle du développement. Besoin d’exécuter des tests contre un AppHost live tout en continuant à développer des fonctionnalités ? Le mode isolé donne à chaque contexte ses propres ports et sa propre config.

Comment ça fonctionne sous le capot

Quand tu passes --isolated, la CLI génère un ID d’instance unique pour l’exécution. Cela pilote deux comportements :

Randomisation des ports — au lieu de se lier à des ports prévisibles définis dans la config de ton AppHost, le mode isolé choisit des ports aléatoires disponibles pour tout — le dashboard, les endpoints de services, tout. Le service discovery s’ajuste automatiquement, pour que les services se trouvent mutuellement quel que soit le port attribué.
Isolation des secrets — chaque exécution isolée obtient son propre store de secrets utilisateur, indexé par l’ID d’instance. Les chaînes de connexion et clés API d’une exécution ne fuient pas dans une autre.

Ton code n’a besoin d’aucun changement. Le service discovery d’Aspire résout les endpoints au runtime, donc tout se connecte correctement quelle que soit l’attribution des ports.

Quand l’utiliser

Utilise --isolated quand tu exécutes plusieurs instances du même AppHost simultanément — que ce soit pour du développement parallèle, des tests automatisés, des agents IA ou des git worktrees. Pour du développement mono-instance où tu préfères des ports prévisibles, le aspire run classique fonctionne toujours très bien.

Pour conclure

Le mode isolé est une petite fonctionnalité qui résout un problème réel et de plus en plus courant. Alors que le développement assisté par IA nous pousse vers plus de workflows parallèles — agents multiples, worktrees multiples, contextes multiples — la capacité de simplement lancer une autre instance sans se battre pour les ports est essentielle.

Lis le post complet pour tous les détails techniques et essaie-le avec aspire update --self pour obtenir la 13.2.

Aspire 13.2 embarque une CLI de documentation — et votre agent IA peut l'utiliser aussi

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

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

Vous connaissez ce moment où vous êtes plongé dans un Aspire AppHost, en train de câbler des intégrations, et vous devez vérifier exactement quels paramètres l’intégration Redis attend ? Vous faites alt-tab vers votre navigateur, vous cherchez sur aspire.dev, vous plissez les yeux sur les docs de l’API, puis vous revenez à votre éditeur. Contexte perdu. Flow brisé.

Aspire 13.2 vient de livrer une solution à ça. La CLI aspire docs vous permet de rechercher, parcourir et lire la documentation officielle d’Aspire directement depuis votre terminal. Et comme elle s’appuie sur des services réutilisables, les agents IA et les skills peuvent utiliser les mêmes commandes pour consulter la doc au lieu d’halluciner des APIs qui n’existent pas.

Le problème que ça résout vraiment

David Pine le dit parfaitement dans le post original : les agents IA étaient catastrophiques pour aider les développeurs à construire des apps Aspire. Ils recommandaient dotnet run au lieu de aspire run, référençaient learn.microsoft.com pour des docs qui se trouvent sur aspire.dev, suggéraient des packages NuGet obsolètes, et — mon préféré — hallucinaient des APIs inexistantes.

Pourquoi ? Parce qu’Aspire a été spécifique à .NET bien plus longtemps qu’il n’est polyglotte, et les LLMs travaillent avec des données d’entraînement qui précèdent les dernières fonctionnalités. Quand vous donnez à un agent IA la capacité de consulter les docs actuels, il arrête de deviner et commence à être utile.

Trois commandes, zéro onglet de navigateur

La CLI est d’une simplicité rafraîchissante :

Lister toute la documentation

aspire docs list

Retourne chaque page de documentation disponible sur aspire.dev. Besoin d’une sortie lisible par une machine ? Ajoutez --format Json.

Rechercher un sujet

aspire docs search "redis"

Recherche à la fois dans les titres et le contenu avec un score de pertinence pondéré. Le même moteur de recherche qui alimente les outils de documentation en interne. Vous obtenez des résultats classés avec titres, slugs et scores de pertinence.

Lire une page complète (ou juste une section)

aspire docs get redis-integration

Envoie la page complète en markdown dans votre terminal. Besoin d’une seule section ?

aspire docs get redis-integration --section "Add Redis resource"

Précision chirurgicale. Pas besoin de scroller 500 lignes. Juste la partie dont vous avez besoin.

L’angle agent IA

C’est là que ça devient intéressant pour nous, développeurs qui construisons avec des outils IA. Les mêmes commandes aspire docs fonctionnent comme outils pour les agents IA — via des skills, des serveurs MCP, ou de simples wrappers CLI.

Au lieu que votre assistant IA invente des APIs Aspire basées sur des données d’entraînement obsolètes, il peut appeler aspire docs search "postgres", trouver les docs d’intégration officiels, lire la bonne page, et vous donner l’approche documentée. De la documentation en temps réel et à jour — pas ce que le modèle a mémorisé il y a six mois.

L’architecture derrière tout ça est intentionnelle. L’équipe Aspire a construit des services réutilisables (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) plutôt qu’une intégration ponctuelle. Cela signifie que le même moteur de recherche fonctionne pour les humains dans le terminal, les agents IA dans votre éditeur, et l’automatisation dans votre pipeline CI.

Scénarios concrets

Consultations rapides dans le terminal : Vous êtes trois fichiers en profondeur et vous avez besoin des paramètres de configuration Redis. Deux commandes, quatre-vingt-dix secondes, retour au travail :

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

Développement assisté par IA : Votre skill VS Code encapsule les commandes CLI. Vous demandez « Ajoute une base de données PostgreSQL à mon AppHost » et l’agent consulte les vrais docs avant de répondre. Pas d’hallucinations.

Validation CI/CD : Votre pipeline valide les configurations AppHost contre la documentation officielle de manière programmatique. La sortie --format Json se connecte proprement à jq et d’autres outils.

Bases de connaissances personnalisées : Vous construisez vos propres outils IA ? Envoyez la sortie JSON structurée directement dans votre base de connaissances :

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Pas de web scraping. Pas de clés API. Les mêmes données structurées utilisées en interne par les outils de documentation.

La documentation est toujours à jour

C’est la partie que j’apprécie le plus. La CLI ne télécharge pas un snapshot — elle interroge aspire.dev avec un cache basé sur les ETags. Dès que la documentation est mise à jour, votre CLI et tout skill construit dessus le reflète. Pas de copies obsolètes, pas de moments « mais le wiki disait… ».

Pour conclure

aspire docs est une de ces petites fonctionnalités qui résout un vrai problème proprement. Les humains obtiennent un accès à la documentation natif au terminal. Les agents IA obtiennent un moyen d’arrêter de deviner et de commencer à référencer de vrais docs. Et tout est soutenu par la même source de vérité.

Si vous construisez avec .NET Aspire et n’avez pas encore essayé la CLI, lancez aspire docs search "votre-sujet-ici" et voyez comment ça se passe. Ensuite, envisagez d’intégrer ces commandes dans votre skill IA ou votre configuration d’automatisation — vos agents vous remercieront.

Consultez l’analyse approfondie de David Pine sur la construction des outils de documentation, et la référence officielle de la CLI pour tous les détails.

Le Dashboard d'Aspire 13.2 a maintenant une API de télémétrie — et ça change tout

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

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

Si vous développez des applications distribuées avec .NET Aspire, vous savez déjà que le dashboard est la meilleure chose de toute l’expérience. Toutes vos traces, logs et métriques au même endroit — pas de Jaeger externe, pas de configuration Seq, pas de moments « laissez-moi vérifier l’autre terminal ».

Aspire 13.2 vient de considérablement améliorer les choses. James Newton-King a annoncé la mise à jour, et honnêtement ? Les fonctionnalités d’export de télémétrie et l’API justifient à elles seules la mise à niveau.

Exporter la télémétrie comme une personne normale

Voici le scénario qu’on a tous vécu : vous déboguez un problème distribué, vous le reproduisez enfin après vingt minutes de configuration, et maintenant vous devez partager ce qui s’est passé avec votre équipe. Avant ? Des captures d’écran. Du copier-coller d’identifiants de traces. Le bazar habituel.

Aspire 13.2 ajoute un dialogue Gérer les logs et la télémétrie où vous pouvez :

Effacer toute la télémétrie (utile avant une tentative de reproduction)
Exporter la télémétrie sélectionnée dans un fichier ZIP au format standard OTLP/JSON
Ré-importer ce ZIP dans n’importe quel dashboard Aspire ultérieurement

Ce dernier point est la fonctionnalité phare. Vous reproduisez un bug, exportez la télémétrie, l’attachez à votre work item, et votre collègue peut l’importer dans son propre dashboard pour voir exactement ce que vous avez vu. Fini le « tu peux reproduire sur ta machine ? »

Les traces, spans et logs individuels ont aussi une option « Export JSON » dans leurs menus contextuels. Besoin de partager une trace spécifique ? Clic droit, copier le JSON, coller dans la description de votre PR. Terminé.

L’API de télémétrie est le vrai changement majeur

C’est ce qui m’enthousiasme le plus. Le dashboard expose maintenant une API HTTP sous /api/telemetry pour interroger les données de télémétrie programmatiquement. Endpoints disponibles :

GET /api/telemetry/resources — lister les ressources avec télémétrie
GET /api/telemetry/spans — interroger les spans avec des filtres
GET /api/telemetry/logs — interroger les logs avec des filtres
GET /api/telemetry/traces — lister les traces
GET /api/telemetry/traces/{traceId} — obtenir tous les spans d’une trace spécifique

Tout revient au format OTLP JSON. Cela alimente les nouvelles commandes CLI aspire agent mcp et aspire otel, mais l’implication réelle est plus grande : vous pouvez maintenant construire des outils, scripts et intégrations d’agents IA qui interrogent directement la télémétrie de votre app.

Imaginez un agent IA de codage qui peut voir vos traces distribuées réelles pendant le débogage. Ce n’est plus hypothétique — c’est ce que cette API permet.

La télémétrie GenAI devient pratique

Si vous construisez des apps alimentées par l’IA avec Semantic Kernel ou Microsoft.Extensions.AI, vous apprécierez le visualiseur de télémétrie GenAI amélioré. Aspire 13.2 ajoute :

Les descriptions d’outils IA rendues en Markdown
Un bouton GenAI dédié sur la page des traces pour un accès rapide
Une meilleure gestion des erreurs pour le JSON GenAI tronqué ou non standard
Une navigation click-to-highlight entre les définitions d’outils

L’article mentionne que VS Code Copilot chat, Copilot CLI et OpenCode supportent tous la configuration d’un OTEL_EXPORTER_OTLP_ENDPOINT. Pointez-les vers le dashboard Aspire et vous pouvez littéralement regarder vos agents IA réfléchir en temps réel via la télémétrie. C’est une expérience de débogage que vous ne trouverez nulle part ailleurs.

Pour conclure

Aspire 13.2 transforme le dashboard d’une « jolie UI de débogage » en « plateforme d’observabilité programmable ». Le workflow d’export/import seul fait gagner du temps réel en débogage distribué, et l’API de télémétrie ouvre la porte au diagnostic assisté par IA.

Si vous êtes déjà sur Aspire, mettez à jour. Sinon — c’est une bonne raison de découvrir aspire.dev.

Aspire | The .NET Blog

Endpoints Privés, VNets, NSGs — Aspire Gère le Réseau Maintenant

Les Blocs de Construction

Le Décrire dans votre AppHost

Pourquoi C’est Important pour les Applications Réelles

Conclusion

Aspire 13.3 : Support Kubernetes, Journaux du Navigateur et la Compétence Aspireify

Aspireify : Intégration Assistée par Agent

Déploiement Kubernetes et AKS de Première Classe

Journaux du Navigateur dans le Dashboard

Résultats de Commandes Structurés

En Résumé

Aspire 13.2 : Support Bun, Meilleurs Conteneurs et Moins de Friction de Debug

Bun est Maintenant Citoyen de Première Classe

Yarn Plus Fiable

Améliorations des Conteneurs

Améliorations du Débogage

Conclusion

Global Azure Spain 2026

Points forts de l’agenda

Billets

Azure Tour 2026

Arrêtez de surveiller votre terminal : le mode détaché d'Aspire change la donne

Mode détaché : une commande, terminal récupéré

Gérer ce qui tourne

Combinez-le avec le mode isolé

Pourquoi c’est énorme pour les agents de code

Pour conclure

.NET Aspire 13.2 Veut Devenir le Meilleur Ami de Votre Agent IA

Le problème est réel

Aspire comme infrastructure pour agents

L’analogie des bumpers de bowling

Pour démarrer

Pour conclure

Le Mode Isolé d'Aspire Résout le Cauchemar des Conflits de Ports pour le Développement Parallèle

La solution : --isolated

Scénarios réels où ça brille

Comment ça fonctionne sous le capot

Quand l’utiliser

Pour conclure

Aspire 13.2 embarque une CLI de documentation — et votre agent IA peut l'utiliser aussi

Le problème que ça résout vraiment

Trois commandes, zéro onglet de navigateur

Lister toute la documentation

Rechercher un sujet

Lire une page complète (ou juste une section)

L’angle agent IA

Scénarios concrets

La documentation est toujours à jour

Pour conclure

Le Dashboard d'Aspire 13.2 a maintenant une API de télémétrie — et ça change tout

Exporter la télémétrie comme une personne normale

L’API de télémétrie est le vrai changement majeur

La télémétrie GenAI devient pratique

Pour conclure

La solution : `--isolated`