Azure Functions au 10 novembre 2026 : .NET 8, .NET 9, PowerShell 7.4 et modèle in-process

Quatre échéances d’Azure Functions tombent le même jour, le 10 novembre 2026 : .NET 8 et .NET 9 dans le modèle isolated worker, le modèle in-process lui-même, qui ne fonctionne qu’avec .NET 8, et PowerShell 7.4. Microsoft l’a rappelé le 23 septembre 2026 par deux entrées des Azure Updates, qui demandent de passer à .NET 10 et à PowerShell 7.6 avant cette date.

Ces quatre fins de support ne demandent pas le même travail. Changer de version .NET dans le modèle isolated worker demande de mettre à jour le projet, ses dépendances et la configuration de l’application. Sortir du modèle in-process est une migration de code. Et une application hébergée sur Linux en plan Consumption doit d’abord changer de plan, parce que ni .NET 10 ni PowerShell 7.6 n’y sont disponibles.

Dates relevées le 29 septembre 2026 sur la documentation Microsoft.

Une version retirée continue de tourner, sans correctifs de sécurité

Les applications ne s’arrêtent pas le 10 novembre 2026. La politique de support des piles de langage d’Azure Functions précise qu’après la date de fin de vie, une application qui utilise une version retirée peut encore être créée, déployée, et continue de tourner sur la plateforme. Elle ne reçoit en revanche plus de nouvelles fonctionnalités, plus de correctifs de sécurité ni d’optimisations de performance tant qu’elle n’a pas été mise à niveau.

Microsoft se réserve aussi, si nécessaire et dans certains cas, de limiter le nombre d’instances allouées à ces applications, jusqu’à une seule instance. Enfin, le support Microsoft exige une mise à niveau avant d’intervenir sur une application qui tourne sur une version non prise en charge.

Pourquoi .NET 9 n’est pas une étape intermédiaire

.NET 9 est une version STS. Sa fin de support était d’abord annoncée pour le 12 mai 2026 ; l’équipe .NET a ensuite porté à 24 mois la durée de support des versions STS, à partir de .NET 9, ce qui la fait tomber le 10 novembre 2026, le même jour que .NET 8. Une application qui passerait de .NET 8 à .NET 9 serait donc hors support à la même date.

La cible est .NET 10, version LTS publiée le 11 novembre 2025 et prise en charge jusqu’au 14 novembre 2028. Le guide de migration de Microsoft donne deux cibles dans le modèle isolated worker : .NET 10 si l’application et ses dépendances peuvent tourner sur .NET, .NET Framework 4.8 si elles dépendent de bibliothèques ou d’API propres à .NET Framework.

Le modèle in-process : passer en isolated worker avant toute version .NET plus récente

Le modèle in-process ne prend en charge que .NET 8. Pour qu’une application Azure Functions in-process passe à une version plus récente de .NET, elle doit d’abord migrer vers le modèle isolated worker. Microsoft fournit un script Azure PowerShell qui liste, dans l’abonnement courant, les applications encore en in-process :

$FunctionApps = Get-AzFunctionApp $AppInfo = @{} foreach ($App in $FunctionApps) { if ($App.Runtime -eq 'dotnet') { $AppInfo.Add($App.Name, $App.Runtime) } } $AppInfo

Le script travaille sur l’abonnement configuré dans Azure PowerShell. Pour en évaluer un autre, lancez d’abord Set-AzContext -Subscription '<YOUR SUBSCRIPTION ID>'.

La migration touche le projet à plusieurs endroits. L’attribut Sdk de l’élément Project passe à Azure.Functions.Sdk/1.0.0. Un fichier Program.cs s’ajoute au projet et remplace le fichier qui porte l’attribut FunctionsStartup, en général Startup.cs. Les signatures des fonctions changent aussi : en général, les attributs de binding d’entrée prennent le suffixe Input et ceux de sortie le suffixe Output, comme CosmosDBInput ou QueueOutput. Côté configuration, le paramètre d’application FUNCTIONS_WORKER_RUNTIME passe de dotnet à dotnet-isolated. Pour une cible .NET 10, Microsoft indique que le .NET Upgrade Assistant peut faire automatiquement nombre de ces changements.

System.Text.Json ignore les attributs Newtonsoft.Json sans le signaler

Le modèle in-process utilisait Newtonsoft.Json ; le modèle isolated worker utilise par défaut System.Text.Json. System.Text.Json ignore les attributs de Newtonsoft.Json tels que [JsonProperty] et [JsonIgnore], et lie alors la propriété concernée à sa valeur par défaut, sans signaler d’erreur. Une fonction qui lit un message dont les noms de champs sont fixés par [JsonProperty] reçoit donc ces propriétés non renseignées, sans erreur au moment de la liaison.

Microsoft propose deux corrections : remplacer ces attributs par leurs équivalents System.Text.Json, comme [JsonPropertyName], ou configurer Newtonsoft.Json pour la couche qui traite ces données.

FUNCTIONS_WORKER_RUNTIME et publication : deux redémarrages, et l’erreur AZFD0013 entre les deux

Dans Azure, la bascule demande deux opérations : passer FUNCTIONS_WORKER_RUNTIME à dotnet-isolated, et publier le projet migré. Chacune redémarre l’application. Entre les deux, le code déployé et le runtime configuré ne correspondent pas, et l’application renvoie l’erreur AZFD0013 jusqu’à la seconde opération.

Microsoft recommande donc de passer par un slot de staging : on y fait les deux changements, on vérifie que les erreurs ont cessé et que l’application fonctionne, puis on échange le slot avec la production, en une seule mise à jour. FUNCTIONS_WORKER_RUNTIME ne doit pas être marqué comme paramètre de slot. Un pipeline CI/CD ou un autre provisionnement automatisé de l’application doit être mis à jour lui aussi, pour conserver dotnet-isolated et viser la bonne version .NET.

Le type d’hébergement décide de l’ordre des opérations

Sur Linux en plan Consumption, .NET 9 est la dernière version .NET prise en charge, et Microsoft n’y ajoute pas les versions suivantes : une application .NET 10 ne peut pas y tourner. La même règle vaut pour PowerShell, dont la version 7.4 est la dernière disponible sur ce plan. Avant de passer à .NET 10 ou à PowerShell 7.6, une telle application doit donc migrer vers le plan Flex Consumption. L’hébergement sur Linux en plan Consumption est lui-même annoncé en retrait pour le 30 septembre 2028, et il ne reçoit plus ni nouvelles fonctionnalités ni nouvelles versions de langage.

Une application in-process sur ce plan cumule donc le changement de modèle, de plan et de version. Flex Consumption ne prend pas en charge la pile dotnet du modèle in-process, et Microsoft demande de migrer d’abord vers le modèle isolated worker. Comme .NET 10 ne tourne pas sur Linux en plan Consumption, l’application change ensuite de plan avant de pouvoir passer à .NET 10.

Le retrait annoncé vise Linux : Microsoft indique que les applications en plan Consumption sur Windows ne sont pas concernées à ce jour. PowerShell 7.6 est pris en charge sur tous les plans sauf Linux Consumption, notamment Premium et Dedicated sous Windows et Linux, Windows Consumption et Flex Consumption.

Deux commandes Azure CLI dressent l’inventaire. az functionapp flex-migration list analyse l’abonnement et renvoie deux listes, eligible_apps et ineligible_apps, avec la raison de chaque incompatibilité. Elle n’évalue que les applications en plan Consumption sur Linux ; pour connaître le plan de toutes les applications, Microsoft donne az functionapp list --query "[].{name:name, sku:sku}" -o table, où la valeur Dynamic désigne le plan Consumption.

Flex Consumption ne propose pas de slots de déploiement

Les procédures de Microsoft pour la migration in-process et pour le changement de version s’appuient sur un slot de staging. Or Flex Consumption ne prend actuellement pas en charge les slots de déploiement. Microsoft conseille de vérifier le code mis à jour dans une application de fonctions hors production, et mentionne la stratégie rolling update pour le déploiement sur une application en service. La présence d’un slot ne bloque pas la migration, mais il faut définir avant la bascule comment l’application sera testée et déployée sans lui.

Changer la version de la pile, puis la vérifier

Hors Flex Consumption, la version de la pile se change dans la configuration de l’application, une fois le code mis à jour et publié, de préférence sur le slot de staging quand il existe. Avec Azure CLI :

• sous Windows, az functionapp config set --net-framework-version "v<VERSION>.0" pour .NET, et --powershell-version "<VERSION>" pour PowerShell ;
• sous Linux, en plan Premium, Dedicated ou Consumption, az functionapp config set --linux-fx-version "<LANGUAGE|VERSION>", avec la valeur que renvoie az functionapp list-runtimes --os linux pour la pile visée.

Chaque commande prend --name, --resource-group et, pour un slot, --slot. La valeur effectivement appliquée se relit avec az functionapp show, sur siteConfig.netFrameworkVersion, siteConfig.linuxFxVersion ou siteConfig.powerShellVersion. Vérifiez aussi que FUNCTIONS_EXTENSION_VERSION vaut ~4 : Microsoft suppose une application déjà en version 4.x du runtime Functions, et renvoie vers ses guides de migration dédiés pour les versions antérieures.

Sans slot, le changement redémarre l’application en production : elle est indisponible pendant une courte période, typiquement 30 à 60 secondes, les requêtes en cours sont interrompues et les nouvelles échouent jusqu’à ce que l’application ait redémarré. Microsoft recommande dans ce cas une fenêtre de maintenance.

Sur Flex Consumption, ces propriétés sont dépréciées et ne doivent pas être employées. La référence des paramètres d’application indique que LinuxFxVersion, netFrameworkVersion et powerShellVersion y sont remplacés par functionAppConfig.runtime, et que FUNCTIONS_EXTENSION_VERSION y est géré par la plateforme et ne doit pas être réglé à la main.

PowerShell 7.4, dans Azure Functions et ailleurs

Dans Azure Functions, PowerShell 7.6 et 7.4 sont les deux versions prises en charge, et 7.4 s’arrête le 10 novembre 2026. PowerShell 7.6, version LTS publiée le 18 mars 2026 sur .NET 10, est prise en charge jusqu’au 14 novembre 2028.

La date dépasse Azure Functions. Le cycle de vie de PowerShell suit celui de la version .NET sur laquelle chaque version est construite : PowerShell 7.4 repose sur .NET 8, et PowerShell 7.5, construit sur .NET 9, s’arrête le même jour. Les scripts d’exploitation qui tournent sous PowerShell 7.4 ou 7.5 sur des serveurs, dans des tâches planifiées ou sur des agents de build sont donc concernés aussi. Windows PowerShell, composant de Windows, suit en revanche le cycle de vie de Windows.

Le 10 novembre 2026 figure aussi, pour .NET 8 et PowerShell 7.4, dans le calendrier des fins de support de l’automne 2026, qui détaille ce qui s’arrête le 13 octobre 2026.

Notre lecture

Nous ne traiterions pas ces quatre fins de support comme une seule échéance, parce qu’elles demandent des efforts sans rapport. Une application déjà en isolated worker sur .NET 8, hébergée en Premium, en Dedicated ou en Flex Consumption, demande un changement de version et une campagne de tests. Une application in-process sur Linux en plan Consumption cumule le modèle d’exécution, le plan d’hébergement et la version .NET, et une fois sur Flex Consumption elle n’a plus de slot pour sécuriser les changements qui restent.

L’inventaire se fait donc sur deux critères : la valeur de FUNCTIONS_WORKER_RUNTIME et le plan d’hébergement. Le script Azure PowerShell de Microsoft et la commande az functionapp list suffisent à le dresser, et nous ouvrons en premier les applications dotnet en plan Dynamic sous Linux. Pour celles-là, nous faisons la migration vers le modèle isolated worker avant le changement de plan, tant que le slot de staging existe encore.

Nous visons .NET 10 directement, sans étape par .NET 9, qui s’arrête le même jour. Et dans une migration in-process, nous testons d’abord la sérialisation, sur des messages réels : la liaison ne signale aucune erreur, et la fonction reçoit ces propriétés à leur valeur par défaut.

Ce qu’il faut vérifier

• La liste des applications dont FUNCTIONS_WORKER_RUNTIME vaut dotnet, obtenue par le script Azure PowerShell de Microsoft, abonnement par abonnement.
• Le plan d’hébergement de chaque application, et en particulier celles en Dynamic sous Linux qui tournent sur .NET ou PowerShell : elles doivent passer par Flex Consumption pour atteindre .NET 10 ou PowerShell 7.6.
• Les applications qui utilisent un slot de déploiement et doivent migrer vers Flex Consumption, pour lesquelles une autre méthode de test et de déploiement est à définir.
• Les types liés par les fonctions qui portent des attributs Newtonsoft.Json comme [JsonProperty] ou [JsonIgnore].
• Les pipelines CI/CD et les modèles d’infrastructure qui fixent FUNCTIONS_WORKER_RUNTIME ou la version de la pile.
• Hors Flex Consumption, la valeur de FUNCTIONS_EXTENSION_VERSION, qui doit être ~4.
• Les applications et scripts PowerShell 7.4 ou 7.5, dans Azure Functions comme sur les serveurs et les agents de build.

Les sources Microsoft

• Retirement: Support for .NET 8 and .NET 9 ends on November 10, 2026
• Retirement: Support for PowerShell 7.4 ends on November 10, 2026
• Azure Functions language stack support policy
• Supported languages in Azure Functions
• Migrate C# apps from the in-process model to the isolated worker model
• Guide for running C# Azure Functions in the isolated worker model
• Update language stack versions in Azure Functions
• App settings reference for Azure Functions
• Migrate Consumption plan apps to the Flex Consumption plan
• Azure Functions Consumption plan hosting
• .NET and .NET Core support policy
• PowerShell support lifecycle