Cloud-Native | 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.

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.

Aspire 13.2 accueille MongoDB EF Core et Azure Data Lake — Deux intégrations à essayer

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

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

Aspire 13.2 vient d’arriver avec deux nouvelles intégrations de bases de données qui méritent votre attention : MongoDB Entity Framework Core et Azure Data Lake Storage. Si vous vouliez utiliser EF Core avec MongoDB dans une app Aspire, ou si vous aviez besoin de connecter des workloads data lake avec du service discovery, cette version apporte les deux.

MongoDB rencontre EF Core dans Aspire

C’est celle qui m’enthousiasme le plus. Aspire supporte MongoDB depuis un moment, mais c’était toujours le driver brut — pas d’EF Core, pas de DbContext, pas de requêtes LINQ sur vos documents. Maintenant vous avez l’expérience complète d’EF Core avec MongoDB, plus les health checks automatiques et le service discovery d’Aspire.

La mise en place suit le pattern typique d’Aspire. Dans votre AppHost :

var mongodb = builder.AddMongoDB("mongodb")
 .WithDataVolume()
 .WithLifetime(ContainerLifetime.Persistent);

var apiService = builder.AddProject<Projects.ApiService>("api")
 .WithReference(mongodb);

Puis dans votre projet consommateur, ajoutez l’intégration EF Core :

dotnet add package Aspire.MongoDB.EntityFrameworkCore

Et enregistrez votre DbContext :

builder.AddMongoDbContext<MyDbContext>("mongodb", "mydb");

À partir de là, c’est de l’EF Core standard. Définissez vos entités, utilisez votre DbContext comme vous le feriez avec n’importe quel autre provider. L’intégration gère le connection pooling, les traces OpenTelemetry et les health checks en arrière-plan.

Pour les développeurs .NET qui utilisaient MongoDB avec le driver brut et configuraient les connection strings manuellement, c’est une belle amélioration. Vous obtenez l’abstraction complète d’EF Core sans perdre le service discovery d’Aspire.

Azure Data Lake Storage entre dans la danse

Le deuxième ajout majeur est une intégration Azure Data Lake Storage (ADLS). Si vous construisez des pipelines de données, des processus ETL ou des plateformes d’analytique, vous pouvez maintenant connecter des ressources Data Lake de la même façon que n’importe quelle autre dépendance Aspire.

Dans l’AppHost :

var storage = builder.AddAzureStorage("azure-storage");
var dataLake = storage.AddDataLake("data-lake");
var fileSystem = storage.AddDataLakeFileSystem("data-lake-file-system");

var analyticsService = builder.AddProject<Projects.AnalyticsService>("analytics")
 .WithReference(dataLake)
 .WithReference(fileSystem);

Dans le projet consommateur :

builder.AddAzureDataLakeServiceClient("data-lake");
builder.AddAzureDataLakeFileSystemClient("data-lake-file-system");

Pas de gestion manuelle de connection strings, pas de recherche de credentials. Aspire provisionne les ressources et les injecte. Pour ceux d’entre nous qui construisent des apps .NET cloud-native touchant à la fois aux données opérationnelles et aux workloads analytiques, cela fait du data lake un citoyen de première classe dans le modèle Aspire.

Les petits correctifs qui comptent

Au-delà des fonctionnalités principales, il y a quelques améliorations à noter :

Correction du connection string MongoDB — le slash avant le nom de la base de données est maintenant géré correctement. Si vous aviez un workaround, vous pouvez le supprimer
Exports SQL Server — Aspire.Hosting.SqlServer exporte maintenant des options de configuration serveur supplémentaires pour un contrôle plus fin
Mises à jour des émulateurs — émulateur ServiceBus 2.0.0, émulateur App Configuration 1.0.2, et l’émulateur preview de CosmosDB inclut maintenant une vérification de disponibilité
Azure Managed Redis — utilise maintenant rediss:// (Redis Secure) par défaut, donc les connexions sont chiffrées d’emblée

Ce dernier point est subtil mais important — un Redis chiffré par défaut signifie une chose de moins à configurer en production.

Pour conclure

Aspire 13.2 est une version incrémentale, mais les intégrations MongoDB EF Core et Data Lake comblent de vrais manques. Si vous attendiez un support EF Core correct avec MongoDB dans Aspire, ou si vous aviez besoin que Data Lake soit une dépendance de première classe, passez à la 13.2 et essayez-les. La commande aspire add génère tout ce dont vous avez besoin.

Lisez les notes de version complètes pour plus de détails, et consultez la galerie d’intégrations pour la liste complète.

Azure Smart Tier est en GA — Optimisation automatique des coûts de Blob Storage sans règles de cycle de vie

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

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

Si vous avez déjà passé du temps à peaufiner les politiques de cycle de vie d’Azure Blob Storage pour ensuite les voir s’effondrer quand les patterns d’accès ont changé, ceci est pour vous. Microsoft vient d’annoncer la disponibilité générale du smart tier pour Azure Blob et Data Lake Storage — une capacité de tiering entièrement gérée qui déplace automatiquement les objets entre les niveaux hot, cool et cold en fonction de l’utilisation réelle.

Ce que fait réellement le smart tier

Le concept est simple : le smart tier évalue en continu la dernière heure d’accès de chaque objet dans votre compte de stockage. Les données fréquemment consultées restent en hot, les données inactives passent en cool après 30 jours, puis en cold après 60 jours supplémentaires. Quand les données sont à nouveau consultées, elles sont repromues en hot immédiatement. Le cycle recommence.

Pas de règles de cycle de vie à configurer. Pas de prédictions de patterns d’accès. Pas de réglages manuels.

Pendant la preview, Microsoft a rapporté que plus de 50% de la capacité gérée par smart tier s’est automatiquement déplacée vers des niveaux plus froids en fonction des patterns d’accès réels. C’est une réduction de coûts significative pour les comptes de stockage volumineux.

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

Si vous développez des applications qui génèrent des logs, de la télémétrie, des données analytiques, ou tout type de patrimoine de données en croissance — et soyons honnêtes, qui ne le fait pas ? — les coûts de stockage s’accumulent vite. L’approche traditionnelle consistait à écrire des politiques de gestion de cycle de vie, les tester, puis les réajuster quand les patterns d’accès de votre application changeaient. Smart tier supprime entièrement ce workflow.

Quelques scénarios pratiques où cela aide :

Télémétrie et logs d’applications — hot lors du débogage, rarement consultés après quelques semaines
Pipelines de données et sorties ETL — sollicités intensément pendant le traitement, puis majoritairement cold
Contenu généré par les utilisateurs — les uploads récents sont hot, le contenu ancien refroidit progressivement
Données de sauvegarde et d’archivage — consultées occasionnellement pour la conformité, majoritairement inactives

Configuration

Activer le smart tier est une configuration unique :

Nouveaux comptes : Sélectionnez smart tier comme niveau d’accès par défaut lors de la création du compte de stockage (redondance zonale requise)
Comptes existants : Changez le niveau d’accès blob de votre valeur par défaut actuelle vers smart tier

Les objets de moins de 128 KiB restent en hot et n’engendrent pas de frais de surveillance. Pour tout le reste, vous payez les tarifs standard de capacité hot/cool/cold sans frais de transition de niveau, sans pénalités de suppression anticipée et sans coûts de récupération de données. Des frais de surveillance mensuels par objet couvrent l’orchestration.

Le compromis à connaître

Les règles de tiering du smart tier sont statiques (30 jours → cool, 90 jours → cold). Si vous avez besoin de seuils personnalisés — par exemple, passer en cool après 7 jours pour un workload spécifique — les règles de cycle de vie restent la solution. Et ne mélangez pas les deux : évitez d’utiliser des règles de cycle de vie sur des objets gérés par smart tier, car elles peuvent entrer en conflit.

Pour conclure

Ce n’est pas révolutionnaire, mais ça résout un vrai casse-tête opérationnel. Si vous gérez des comptes blob storage en croissance et que vous en avez assez de maintenir des politiques de cycle de vie, activez smart tier et laissez Azure s’en charger. C’est disponible dès aujourd’hui dans la quasi-totalité des régions zonales du cloud public.

Où héberger vos agents IA sur Azure ? Un guide de décision pratique

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

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

Si vous construisez des agents IA avec .NET en ce moment, vous avez probablement remarqué quelque chose : il y a beaucoup de façons de les héberger sur Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — et tous semblent raisonnables jusqu’à ce que vous ayez réellement besoin d’en choisir un. Microsoft vient de publier un guide complet sur l’hébergement d’agents IA sur Azure qui clarifie tout ça, et je veux le décomposer du point de vue pratique d’un développeur .NET.

Les six options en un coup d’œil

Voici comment je résumerais le paysage :

Option	Idéal pour	Vous gérez
Container Apps	Contrôle total des conteneurs sans complexité K8s	Observabilité, état, cycle de vie
AKS	Conformité entreprise, multi-cluster, réseau personnalisé	Tout (c’est le but)
Azure Functions	Tâches d’agents événementielles et courtes	Presque rien — vrai serverless
App Service	Agents HTTP simples, trafic prévisible	Déploiement, config de scaling
Foundry Agents	Agents sans code via portail/SDK	Presque rien
Foundry Hosted Agents	Agents framework personnalisé avec infra gérée	Uniquement votre code d’agent

Les quatre premières sont du compute généraliste — vous pouvez y exécuter des agents, mais elles n’ont pas été conçues pour ça. Les deux dernières sont natives aux agents : elles comprennent les conversations, les appels d’outils et les cycles de vie des agents comme des concepts de première classe.

Foundry Hosted Agents — le sweet spot pour les développeurs .NET d’agents

C’est ce qui a attiré mon attention. Les Foundry Hosted Agents se situent pile au milieu : vous obtenez la flexibilité d’exécuter votre propre code (Semantic Kernel, Agent Framework, LangGraph — peu importe) mais la plateforme gère l’infrastructure, l’observabilité et la gestion des conversations.

La pièce clé est le Hosting Adapter — une fine couche d’abstraction qui connecte votre framework d’agents à la plateforme Foundry. Pour Microsoft Agent Framework, ça ressemble à ça :

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

C’est toute votre histoire d’hébergement. L’adapter gère la traduction de protocoles, le streaming via server-sent events, l’historique de conversation et le traçage OpenTelemetry — tout automatiquement. Pas de middleware personnalisé, pas de plomberie manuelle.

Le déploiement est vraiment simple

J’ai déployé des agents sur Container Apps avant et ça fonctionne, mais on finit par écrire beaucoup de code de colle pour la gestion d’état et l’observabilité. Avec Hosted Agents et azd, le déploiement c’est :

# Installer l'extension agent IA
azd ext install azure.ai.agents

# Initialiser depuis un template
azd ai agent init

# Construire, pousser, déployer — terminé
azd up

Ce seul azd up construit votre conteneur, le pousse vers ACR, provisionne le projet Foundry, déploie les endpoints de modèle et démarre votre agent. Cinq étapes condensées en une seule commande.

Gestion de conversations intégrée

C’est la partie qui fait gagner le plus de temps en production. Au lieu de construire votre propre store d’état de conversation, les Hosted Agents le gèrent nativement :

# Créer une conversation persistante
conversation = openai_client.conversations.create()

# Premier tour
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Deuxième tour — le contexte est préservé
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Pas de Redis. Pas de store de sessions Cosmos DB. Pas de middleware personnalisé pour la sérialisation des messages. La plateforme gère tout simplement.

Mon framework de décision

Après avoir passé en revue les six options, voici mon modèle mental rapide :

Vous avez besoin de zéro infrastructure ? → Foundry Agents (portail/SDK, pas de conteneurs)
Vous avez du code d’agent personnalisé mais voulez un hébergement géré ? → Foundry Hosted Agents
Vous avez besoin de tâches d’agents événementielles et courtes ? → Azure Functions
Vous avez besoin d’un contrôle maximum des conteneurs sans K8s ? → Container Apps
Vous avez besoin de conformité stricte et multi-cluster ? → AKS
Vous avez un agent HTTP simple avec un trafic prévisible ? → App Service

Pour la plupart des développeurs .NET qui construisent avec Semantic Kernel ou Microsoft Agent Framework, Hosted Agents est probablement le bon point de départ. Vous obtenez le scale-to-zero, OpenTelemetry intégré, la gestion des conversations et la flexibilité de framework — sans gérer Kubernetes ni monter votre propre stack d’observabilité.

Pour conclure

Le paysage de l’hébergement d’agents sur Azure mûrit rapidement. Si vous démarrez un nouveau projet d’agent IA aujourd’hui, je considérerais sérieusement Foundry Hosted Agents avant de recourir à Container Apps ou AKS par habitude. L’infrastructure gérée fait gagner un temps réel, et le pattern hosting adapter vous permet de garder votre choix de framework.

Consultez le guide complet de Microsoft et le repo Foundry Samples pour des exemples fonctionnels.

KubeCon Europe 2026 : Ce que les développeurs .NET devraient vraiment retenir

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

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

Vous connaissez cette sensation quand un énorme post d’annonces tombe et que vous scrollez en pensant « cool, mais concrètement ça change quoi pour moi » ? C’est moi à chaque saison KubeCon.

Microsoft vient de publier son récapitulatif complet de KubeCon Europe 2026 — écrit par Brendan Burns en personne — et honnêtement ? Il y a du vrai contenu ici. Pas juste des cases à cocher, mais des améliorations opérationnelles qui changent votre façon de gérer les choses en production.

Laissez-moi décortiquer ce qui compte vraiment pour nous développeurs .NET.

mTLS sans la taxe du service mesh

Voici le truc avec les service meshes : tout le monde veut les garanties de sécurité, personne ne veut la charge opérationnelle. AKS comble enfin cet écart.

Azure Kubernetes Application Network vous donne le TLS mutuel, l’autorisation consciente de l’application et la télémétrie du trafic — sans déployer un mesh complet avec sidecars. Combiné avec Cilium mTLS dans Advanced Container Networking Services, vous obtenez une communication chiffrée pod-à-pod utilisant des certificats X.509 et SPIRE pour la gestion des identités.

Ce que ça signifie en pratique : vos APIs ASP.NET Core qui communiquent avec des workers en arrière-plan, vos services gRPC qui s’appellent mutuellement — tout chiffré et vérifié au niveau réseau, sans aucune modification de code. C’est énorme.

Pour les équipes qui migrent depuis ingress-nginx, il y a aussi Application Routing avec Meshless Istio avec support complet de Kubernetes Gateway API. Pas de sidecars. Basé sur les standards. Et ils ont livré des outils ingress2gateway pour une migration incrémentale.

Observabilité GPU qui n’est pas une pensée après coup

Si vous exécutez de l’inférence IA aux côtés de vos services .NET (et soyons honnêtes, qui ne commence pas ?), vous avez probablement rencontré l’angle mort du monitoring GPU. Vous aviez de super dashboards CPU/mémoire et ensuite… rien pour les GPU sans configuration manuelle d’exporteurs.

AKS expose maintenant les métriques GPU nativement dans Prometheus et Grafana managés. Même stack, mêmes dashboards, même pipeline d’alertes. Pas d’exporteurs custom, pas d’agents tiers.

Côté réseau, ils ont ajouté de la visibilité par flux pour le trafic HTTP, gRPC et Kafka avec une expérience Azure Monitor en un clic. IPs, ports, workloads, direction des flux, décisions de policies — tout dans des dashboards intégrés.

Et voici celle qui m’a fait regarder deux fois : agentic container networking ajoute une interface web où vous pouvez poser des questions en langage naturel sur l’état réseau de votre cluster. « Pourquoi le pod X n’atteint-il pas le service Y ? » → diagnostics en lecture seule depuis la télémétrie en direct. C’est vraiment utile à 2h du matin.

Networking cross-cluster sans avoir besoin d’un doctorat

Le multi-cluster Kubernetes a toujours été une expérience « apportez votre propre colle réseau ». Azure Kubernetes Fleet Manager propose maintenant du networking cross-cluster via un cluster mesh Cilium managé :

Connectivité unifiée entre clusters AKS
Registre global de services pour la découverte cross-cluster
Configuration gérée centralement, pas répétée par cluster

Si vous exécutez des microservices .NET sur plusieurs régions pour la résilience ou la conformité, ça remplace beaucoup de colle custom fragile. Le Service A en West Europe peut découvrir et appeler le Service B en East US à travers le mesh, avec des politiques de routage et de sécurité cohérentes.

Des mises à jour qui ne demandent pas du courage

Soyons honnêtes — les mises à jour Kubernetes en production sont stressantes. « Mettre à jour et espérer » a été la stratégie de fait pour trop d’équipes, et c’est la raison principale pour laquelle les clusters restent en retard sur les versions.

Deux nouvelles capacités changent la donne :

Les blue-green agent pool upgrades créent un pool de nœuds parallèle avec la nouvelle configuration. Validez le comportement, déplacez le trafic progressivement et gardez un chemin de rollback propre. Plus de mutations in-place sur les nœuds de production.

Le rollback d’agent pool permet de revenir à la version Kubernetes et l’image de nœud précédentes d’un pool après qu’une mise à jour se passe mal — sans reconstruire le cluster.

Ensemble, ils donnent enfin aux opérateurs un vrai contrôle sur le cycle de vie des mises à jour. Pour les équipes .NET, c’est important car la vélocité de la plateforme contrôle directement la vitesse à laquelle vous pouvez adopter de nouveaux runtimes, patchs de sécurité et capacités réseau.

Les workloads IA deviennent des citoyens de première classe Kubernetes

Le travail upstream en open-source est tout aussi important. Dynamic Resource Allocation (DRA) vient de passer en GA dans Kubernetes 1.36, faisant du scheduling GPU une vraie fonctionnalité de première classe plutôt qu’un contournement.

Quelques projets à surveiller :

Projet	Ce qu’il fait
AI Runway	API Kubernetes commune pour l’inférence — déployez des modèles sans connaître K8s, avec découverte HuggingFace et estimations de coûts
HolmesGPT	Dépannage agentique pour le cloud-native — maintenant un projet CNCF Sandbox
Dalec	Builds déclaratifs d’images de conteneur avec génération de SBOM — moins de CVE à l’étape de build

La direction est claire : votre API .NET, votre couche d’orchestration Semantic Kernel et vos workloads d’inférence devraient tous tourner sur un modèle de plateforme cohérent. On y arrive.

Par où commencer cette semaine

Si vous évaluez ces changements pour votre équipe, voici ma liste de priorités honnête :

L’observabilité d’abord — activez les métriques GPU et les logs de flux réseau dans un cluster non-prod. Voyez ce que vous avez manqué.
Testez les blue-green upgrades — essayez le workflow de rollback avant votre prochaine mise à jour de cluster en production. Construisez la confiance dans le processus.
Pilotez le networking identity-aware — choisissez un chemin de service interne et activez mTLS avec Cilium. Mesurez l’overhead (spoiler : c’est minimal).
Évaluez Fleet Manager — si vous gérez plus de deux clusters, le networking cross-cluster se rentabilise tout seul en réduisant la colle custom.

Petites expériences, feedback rapide. C’est toujours le bon choix.

Pour conclure

Les annonces KubeCon peuvent être accablantes, mais cette fournée fait vraiment bouger les choses pour les équipes .NET sur AKS. Meilleure sécurité réseau sans overhead de mesh, vraie observabilité GPU, mises à jour plus sûres et des fondations d’infrastructure IA plus solides.

Si vous êtes déjà sur AKS, c’est un excellent moment pour renforcer votre baseline opérationnel. Et si vous prévoyez de migrer des workloads .NET vers Kubernetes — la plateforme vient de devenir nettement plus prête pour la production.