Azure Functions : 1.x → 4.x en 12 Étapes [2026]

Le compte à rebours est lancé. Microsoft coupera le support du runtime Azure Functions 1.x le 14 septembre 2026, soit dans onze jours, comme le confirme la documentation officielle des versions de runtime. Passé cette date, les applications encore sur cette version continueront probablement de tourner, mais elles ne recevront plus aucun correctif de sécurité ni mise à jour. Pour toute équipe qui exploite encore des Function Apps héritées en .NET Framework, c’est le moment de migrer, pas de reporter. Ce tutoriel détaille les 12 étapes concrètes pour passer du runtime 1.x au runtime 4.x, avec les commandes exactes, les pièges à éviter et un projet complet migré de A à Z.

Pourquoi migrer avant le 14 septembre 2026

Le runtime 1.x d’Azure Functions est en mode maintenance depuis plusieurs années. Il ne prend en charge que les applications C# ciblant .NET Framework 4.8, et Microsoft ne lui ajoute plus aucune fonctionnalité. La documentation officielle est claire sur ce point : le support s’arrête le 14 septembre 2026, et les équipes doivent migrer leurs applications vers la version 4.x pour continuer à bénéficier d’un support complet. Le runtime 4.x est aujourd’hui la version recommandée pour tous les langages pris en charge par Azure Functions, avec un statut de disponibilité générale (GA) stable.

Le calendrier ne s’arrête pas au 14 septembre. Pour les applications .NET, Microsoft retire aussi le modèle d’exécution in-process : son support cesse le 10 novembre 2026, au profit du modèle isolated worker. Deux échéances proches, donc, qui obligent à traiter la migration comme un seul chantier plutôt que deux projets séparés. Une app encore pinnée sur une version mineure ancienne du runtime (antérieure à 1.0.20776.0 pour la 1.x, ou antérieure à 4.24.0.0 pour la 4.x) doit d’abord basculer vers la dernière version disponible avant d’entamer la bascule majeure.

Cette migration touche aussi les équipes qui gèrent du serverless sur d’autres clouds. Si vous comparez les options, notre tutoriel sur le déploiement AWS Lambda montre à quel point les cycles de dépréciation de runtime sont désormais la norme chez tous les fournisseurs cloud, pas seulement chez Microsoft.

Le contexte : pourquoi Microsoft resserre le calendrier des runtimes serverless

Azure Functions n’est pas le seul service à imposer ce type de bascule cette année. Docker Engine a publié coup sur coup deux versions correctives en juillet 2026, la 29.6.2 puis la 29.7.0, pour colmater plusieurs failles dans BuildKit, dont une permettant l’exécution de commandes via un checkout Git malveillant. Kubernetes a de son côté atteint la disponibilité générale de sa version 1.37 le 26 août 2026, avec seize fonctionnalités promues au statut stable. Ces échéances rapprochées ne sont pas une coïncidence isolée : les grands éditeurs cloud raccourcissent leurs fenêtres de support pour réduire la surface d’attaque exposée par du code ancien, une tendance de fond que l’on retrouve aussi bien dans l’écosystème conteneurs que dans le serverless.

Pour Azure Functions spécifiquement, la note d’annonce App Service d’octobre 2025 précise déjà que les applications pinnées sur une version mineure ancienne du runtime devront d’abord évoluer vers la dernière version disponible de leur branche majeure, avant même d’envisager la bascule vers le 4.x. Ignorer cette étape intermédiaire est l’une des raisons les plus fréquentes d’échec de migration observées sur le terrain, en particulier pour les applications qui n’ont pas été redéployées depuis plusieurs années.

Runtime 1.x vs 4.x : ce qui change concrètement

Avant de toucher au code, il faut comprendre ce que la bascule modifie réellement. Le tableau ci-dessous résume les écarts entre les versions actives du runtime, tels que documentés par Microsoft Learn.

Runtime	Statut	Fin de support	Modèles disponibles
1.x	Maintenance	14 septembre 2026	In-process, .NET Framework 4.8 uniquement
3.x (plan Linux Consumption)	Fin de vie	Arrêt d’exécution le 30 septembre 2026	In-process
4.x (in-process)	Support limité	10 novembre 2026	.NET 8.0 uniquement
4.x (isolated worker)	GA, recommandé	Support actif	.NET 10, .NET 9.0, .NET 8.0, .NET Framework 4.8

Trois points méritent une attention particulière. D’abord, le runtime 4.x charge ses bindings via des extension bundles déclarés dans host.json, alors que le 1.x s’appuyait sur des extensions préinstallées. Ensuite, le modèle isolated worker exécute votre code dans son propre processus .NET, séparé du processus hôte Functions, ce qui change la façon dont on démarre l’application (Program.cs remplace les attributs de classe implicites). Enfin, les matrices de langages supportés ont bougé : une app Node.js ou Python qui tournait sur une version ancienne du runtime doit souvent aussi remonter sa version de langage pour rester dans le périmètre supporté par le 4.x.

La ligne 3.x mérite une mention à part. Elle n’apparaît plus dans les nouveaux projets depuis longtemps, mais elle subsiste sur d’anciennes Function Apps en plan Linux Consumption, où elle cessera purement et simplement de s’exécuter le 30 septembre 2026. Contrairement au 1.x, dont le support s’arrête sans coupure immédiate du service, une app 3.x sur ce plan précis ne redémarrera pas après cette date tant qu’elle n’aura pas été migrée. Si votre audit de l’étape 1 révèle des apps dans cette configuration, traitez-les en priorité absolue, avant même les apps 1.x qui disposent d’une marge un peu plus large.

Prérequis : outils, versions et comptes nécessaires

Avant de démarrer, réunissez les éléments suivants. Cette liste évite les allers-retours une fois la migration commencée.

Un abonnement Azure actif avec les droits Contributeur sur le groupe de ressources hébergeant vos Function Apps
Azure Functions Core Tools en version 4.14.0 ou supérieure (publiée le 24 août 2026 sur npm)
Node.js 20 LTS ou plus récent pour exécuter Core Tools localement
Azure CLI à jour, avec les commandes functionapp disponibles
Azurite comme émulateur de stockage local (l’ancien Storage Emulator Windows n’est plus recommandé)
Un accès Git au dépôt du projet, pour créer une branche de migration dédiée
Visual Studio 2022 ou Visual Studio Code avec l’extension Azure Functions, si vos apps sont en .NET
Application Insights déjà connecté à vos Function Apps, pour comparer le comportement avant et après bascule

Vérifiez aussi la version actuelle de vos apps en production avant de commencer. C’est l’objet de la première étape.

Combien de temps prévoir pour cette migration

Pour une Function App simple, avec un seul déclencheur HTTP et peu de dépendances externes, comptez environ 90 à 120 minutes en suivant les 12 étapes de ce tutoriel de bout en bout, tests locaux et validation en slot de staging inclus. Ce chiffre grimpe rapidement pour les applications plus complexes : une app .NET qui doit basculer du modèle in-process vers isolated worker demande généralement une demi-journée supplémentaire, le temps de réécrire le point d’entrée et de valider chaque binding un par un. Une app avec plusieurs déclencheurs Event Hub ou Cosmos DB ajoute encore du temps de test, car chaque binding doit être vérifié individuellement après la mise à jour de l’extension bundle.

Si vous gérez un parc de plusieurs dizaines d’applications, ne traitez pas la migration app par app dans l’urgence. Regroupez-les par langage et par type de binding, migrez d’abord un échantillon représentatif de chaque groupe, puis industrialisez le reste une fois le modèle validé. Cette approche réduit le temps total bien plus efficacement qu’une migration séquentielle improvisée à la dernière minute.

Étape 1 : Auditer votre parc d’applications Function

Commencez par lister toutes les Function Apps de votre abonnement et leur version de runtime actuelle. La commande interroge le paramètre d’application FUNCTIONS_EXTENSION_VERSION, qui pilote la version ciblée par chaque app, comme l’explique la documentation sur le ciblage des versions de runtime.

az functionapp config appsettings list \
  --name mon-app-fonction \
  --resource-group mon-groupe-ressources \
  --query "[?name=='FUNCTIONS_EXTENSION_VERSION']"

Une valeur de ~1 signale une app encore sur le runtime 1.x, une valeur ~3 sur le 3.x, et ~4 confirme une app déjà migrée. Répétez la commande pour chaque app, ou scriptez la boucle sur l’ensemble du groupe de ressources avec az functionapp list. Notez au passage le langage de chaque app (C#, Node.js, Python, PowerShell ou Java) et son plan d’hébergement (Consumption, Premium ou App Service), car ces deux paramètres influencent l’ordre de priorité de la migration. Les apps sur plan Linux Consumption tournant encore en 3.x sont les plus urgentes : elles cessent purement et simplement de fonctionner le 30 septembre 2026.

Étape 2 : Installer Azure Functions Core Tools 4.14.0

La documentation Microsoft sur le développement local est catégorique sur ce point : la version majeure de Core Tools installée en local doit correspondre à la version majeure ciblée par l’app dans Azure. Installez donc la ligne 4.x avant d’aller plus loin. La dernière version publiée au moment de la rédaction est la 4.14.0, sortie le 24 août 2026 sur le registre npm.

npm install -g azure-functions-core-tools@4 --unsafe-perm true
func --version

La commande func --version doit retourner 4.14.0 ou une version ultérieure. Si une ancienne installation de Core Tools traîne encore sur la machine (v1, v2 ou v3), désinstallez-la avant de réinstaller la v4, sinon le PATH système peut pointer vers le mauvais binaire et provoquer des erreurs de version au démarrage local.

Étape 3 : Sauvegarder l’existant et créer une branche de migration

Exportez la configuration actuelle de chaque Function App avant toute modification. Cette sauvegarde sert de filet en cas de rollback.

az functionapp config appsettings list \
  --name mon-app-fonction \
  --resource-group mon-groupe-ressources > backup-appsettings.json

git checkout -b migration/runtime-4x

Travaillez sur cette branche jusqu’à ce que les tests locaux et le slot de staging valident la migration. Ne touchez jamais directement à la branche principale tant que la bascule n’est pas confirmée en production, ce qui rejoint les bonnes pratiques déjà couvertes dans notre guide sur le pipeline CI/CD Azure DevOps, où chaque changement de runtime passe par une validation automatisée avant fusion.

Étape 4 : Mettre à jour host.json vers le schéma 2.0

C’est le changement le plus fréquemment oublié, et celui qui casse le plus de migrations. Le guide officiel de migration 1.x vers 4.x précise qu’il faut ajouter à la fois l’élément version et l’élément extensionBundle dans host.json. Sans ce bloc, le runtime 4.x ne sait plus charger les bindings et l’application refuse de démarrer.

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  },
  "logging": {
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true
      }
    }
  }
}

La plage de version entre crochets fixe une borne inférieure et une borne supérieure exclusive. Elle permet à Azure d’installer automatiquement les correctifs mineurs de l’extension bundle sans jamais sauter vers une version majeure incompatible. Comparez ce fichier à votre host.json 1.x d’origine, qui n’avait souvent ni version ni extensionBundle explicites, et vous comprendrez pourquoi tant de bindings cessaient de fonctionner après une bascule mal préparée.

Étape 5 : Migrer les bindings avec les extension bundles

Une fois l’extension bundle déclaré, vérifiez chaque binding utilisé par vos fonctions (Storage Queue, Blob, Cosmos DB, Event Hub, Service Bus, Timer). Le comportement par défaut de certains déclencheurs a changé entre le 1.x et le 4.x, en particulier les paramètres de taille de lot et de concurrence pour les déclencheurs Storage et Event Hub. Reprenez ces valeurs dans la section host.json correspondant à chaque extension, plutôt que de laisser les valeurs par défaut du bundle s’appliquer sans contrôle.

Testez chaque binding individuellement après la migration. Un déclencheur Cosmos DB qui ne se déclenche plus après la bascule pointe presque toujours vers une plage de version d’extension bundle trop restrictive, qui exclut la version de l’extension Cosmos DB réellement nécessaire. Construisez une checklist par type de binding (déclenchement effectif, données reçues au bon format, sortie correctement écrite) et cochez-la application par application plutôt que de vous fier à un test global qui masquerait un binding secondaire resté silencieusement cassé.

Étape 6 : Adapter function.json et les déclencheurs

Pour les fonctions écrites en JavaScript, Python ou PowerShell, chaque dossier de fonction conserve son fichier function.json. Vérifiez que les propriétés direction, dataType et authLevel sont explicites, car certaines extensions 4.x n’appliquent plus les mêmes valeurs par défaut que le 1.x.

{
  "bindings": [
    {
      "authLevel": "function",
      "type": "httpTrigger",
      "direction": "in",
      "name": "req",
      "methods": ["get", "post"]
    },
    {
      "type": "http",
      "direction": "out",
      "name": "$return"
    }
  ]
}

Si vos fonctions HTTP utilisaient un niveau d’autorisation anonyme par défaut sous le 1.x, déclarez-le explicitement en function ou anonymous selon vos besoins réels. Le 4.x n’infère plus ce paramètre de la même façon, et une fonction publique par erreur après migration est un risque de sécurité concret, pas une hypothèse théorique.

Étape 7 : Passer du modèle in-process au modèle isolated worker (.NET)

Pour les applications .NET, c’est l’étape la plus structurante. Le modèle in-process s’arrête le 10 novembre 2026, ce qui rend la migration vers isolated worker quasi obligatoire si vos apps sont en .NET. Le nouveau modèle démarre l’application via un HostBuilder explicite, dans un processus séparé du runtime Functions.

using Microsoft.Extensions.Hosting;
using Microsoft.Azure.Functions.Worker;

var host = new HostBuilder()
    .ConfigureFunctionsWebApplication()
    .ConfigureServices(services =>
    {
        services.AddApplicationInsightsTelemetryWorkerService();
        services.ConfigureFunctionsApplicationInsights();
    })
    .Build();

host.Run();

Le fichier csproj change aussi de forme : le SDK cible Microsoft.NET.Sdk avec le package Microsoft.Azure.Functions.Worker, plutôt que Microsoft.NET.Sdk.Functions utilisé par l’in-process. Le modèle isolated worker fonctionne avec .NET 8.0, .NET 9.0 et .NET 10, ce qui vous laisse une marge confortable pour planifier vos futures montées de version sans repasser par une migration de modèle d’exécution.

Attendez-vous à quelques ajustements de code au-delà du point d’entrée. L’injection de dépendances passe désormais par le conteneur de services standard de .NET plutôt que par les mécanismes propres au modèle in-process, et la sérialisation des objets de requête et de réponse HTTP change de forme dans certains cas. Testez en particulier les fonctions qui manipulent des en-têtes HTTP personnalisés ou des corps de requête binaires, car ce sont les points où les deux modèles divergent le plus concrètement.

Étape 8 : Mettre à jour Node.js et Python vers les versions supportées

Le guide de migration officiel demande explicitement de basculer vers une version de Node.js prise en charge par le runtime 4.x. Une app Node.js encore sur une version ancienne échouera au démarrage, même avec un host.json correctement mis à jour. Le principe est le même côté Python : la matrice de support 4.x a évolué, et une version de Python valide sous le 1.x peut ne plus l’être aujourd’hui.

# Vérifier la version de langage déclarée pour l'app
az functionapp config show \
  --name mon-app-fonction \
  --resource-group mon-groupe-ressources \
  --query "linuxFxVersion"

Croisez le résultat avec la matrice de versions publiée par Microsoft pour le runtime 4.x, langage par langage. Ne vous fiez pas à la documentation générique trouvée dans un ancien tutoriel : ces matrices changent à chaque montée de version majeure du runtime, et une version supportée il y a deux ans peut avoir été retirée depuis. Pour les applications Python en particulier, vérifiez aussi la version du système d’exploitation sous-jacent du plan d’hébergement : une image Linux ancienne peut bloquer l’installation de certaines dépendances natives même quand la version de Python elle-même est correcte.

Étape 9 : Configurer Azurite et tester en local

Azurite remplace l’ancien Storage Emulator Windows comme émulateur de stockage local recommandé pour Azure Functions. Installez-le et démarrez-le avant de lancer vos tests locaux, surtout si vos fonctions dépendent de bindings Blob, Queue ou Table.

npm install -g azurite
azurite --silent --location ./azurite-data --debug ./azurite-data/debug.log

Azurite écoute par défaut sur les ports 10000 (Blob), 10001 (Queue) et 10002 (Table). Vérifiez qu’aucun autre service ne monopolise ces ports avant de démarrer, sinon Azurite échoue silencieusement au lancement et vos tests locaux échouent pour une raison qui n’a rien à voir avec la migration elle-même. Si votre équipe travaille avec Docker au quotidien, une alternative consiste à lancer Azurite dans un conteneur dédié plutôt qu’en global npm, ce qui isole proprement l’environnement de test d’un projet à l’autre et évite les conflits de version d’Azurite entre plusieurs dépôts.

Étape 10 : Tester l’application en local avec func start

Une fois Azurite lancé, démarrez l’application avec Core Tools et vérifiez chaque endpoint un par un.

func start --verbose

Un exemple de sortie attendue pour une fonction HTTP correctement migrée ressemble à ceci :

Azure Functions Core Tools
Core Tools Version:       4.14.0
Function Runtime Version: 4.1039.0

Functions:
        HttpExample: [GET,POST] http://localhost:7071/api/HttpExample

For detailed output, run func with --verbose flag.

Si cette sortie n’apparaît pas, ou si le numéro de Function Runtime Version reste bloqué sur une valeur 1.x, le problème vient presque toujours d’un host.json mal formé ou d’un mélange de versions entre Core Tools et le SDK du projet. Corrigez avant de passer à l’étape suivante : un test local qui échoue silencieusement se reproduira en production, avec un impact bien plus coûteux à diagnostiquer.

Étape 11 : Déployer sur un slot de staging Azure

Ne basculez jamais directement en production. Créez un slot de déploiement dédié, déployez-y le code migré, et configurez-le sur le runtime 4.x avant de toucher au slot principal.

az functionapp deployment slot create \
  --name mon-app-fonction \
  --resource-group mon-groupe-ressources \
  --slot staging

az functionapp config appsettings set \
  --name mon-app-fonction \
  --resource-group mon-groupe-ressources \
  --slot staging \
  --settings FUNCTIONS_EXTENSION_VERSION=~4

func azure functionapp publish mon-app-fonction --slot staging

Laissez le slot de staging tourner sous une charge réelle pendant au moins 24 à 48 heures avant de valider la bascule finale. Surveillez les métriques Application Insights (taux d’erreur, durée d’exécution, cold starts) et comparez-les à celles du slot de production sur la même période. Si votre organisation optimise déjà ses coûts cloud, notre guide FinOps détaille comment ce type de comparaison de métriques avant et après une migration technique se traduit directement en économies mesurables sur la facture.

Étape 12 : Basculer FUNCTIONS_EXTENSION_VERSION en production

Une fois le slot de staging validé, échangez-le avec le slot de production. Cette opération est quasiment instantanée et réversible en cas de problème.

az functionapp deployment slot swap \
  --name mon-app-fonction \
  --resource-group mon-groupe-ressources \
  --slot staging \
  --target-slot production

Surveillez les 30 premières minutes après la bascule de près. Gardez la commande de rollback sous la main : un simple nouveau swap dans le sens inverse restaure l’état précédent si un comportement inattendu apparaît. Documentez ensuite la migration (date, version finale, incidents rencontrés) pour que l’équipe suivante n’ait pas à refaire cette recherche dans six mois, lors de la prochaine montée de version majeure.

Prévoyez aussi une fenêtre d’observation plus longue que les 30 premières minutes pour les applications à trafic irrégulier. Une fonction déclenchée par un traitement de nuit ou une tâche planifiée hebdomadaire ne montrera son comportement réel qu’au prochain cycle d’exécution, parfois plusieurs jours après le swap. Gardez le slot précédent disponible pendant au moins une semaine avant de le considérer comme obsolète, le temps que tous les scénarios d’usage se soient exécutés au moins une fois sur la nouvelle version.

Projet complet : une fonction HTTP Node.js migrée de bout en bout

Voici l’arborescence complète d’une fonction HTTP simple, entièrement conforme au runtime 4.x, prête à être déployée telle quelle.

mon-projet/
├── host.json
├── local.settings.json
├── package.json
└── HttpExample/
    ├── function.json
    └── index.js

// package.json
{
  "name": "http-example-fonction",
  "version": "1.0.0",
  "main": "HttpExample/index.js",
  "engines": {
    "node": ">=20.0.0"
  },
  "dependencies": {
    "@azure/functions": "^4.0.0"
  }
}

// local.settings.json (utilisé uniquement en local, jamais commité)
{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "node"
  }
}

// HttpExample/index.js
module.exports = async function (context, req) {
    const nom = (req.query.nom || (req.body && req.body.nom));
    const message = nom
        ? `Bonjour ${nom}, cette fonction tourne sur le runtime 4.x.`
        : "Ajoutez un paramètre 'nom' dans l'URL ou le corps de la requête.";

    context.res = {
        status: 200,
        body: message
    };
};

Ce projet minimal réunit les quatre briques indispensables couvertes dans ce tutoriel : un host.json avec extensionBundle correctement borné, un function.json aux directions et types explicites, une version de Node.js déclarée dans package.json, et un local.settings.json qui pointe vers Azurite plutôt que vers un vrai compte de stockage. Ce dernier fichier ne doit jamais être versionné dans Git : il contient potentiellement des chaînes de connexion, et son placement dans le .gitignore fait partie des vérifications à ne pas oublier avant de pousser la branche de migration. Déployez ce projet sur un slot de staging avec la commande de l’étape 11, validez-le, puis basculez-le en production avec celle de l’étape 12.

Pièges courants à éviter pendant la migration

Oublier extensionBundle dans host.json. C’est la cause numéro un de bindings qui cessent de fonctionner après la bascule, et elle passe souvent inaperçue en local si les tests ne couvrent pas tous les déclencheurs.
Garder une version de runtime épinglée. Une app pinnée sur une ancienne version mineure du 1.x ou du 4.x n’hérite pas automatiquement des correctifs, ce qui fausse les résultats de test.
Confondre modèle in-process et isolated worker. Déployer un projet isolated worker avec un fichier csproj resté configuré pour l’in-process produit des erreurs de démarrage difficiles à diagnostiquer.
Ignorer la matrice de versions de langage. Une version de Node.js ou Python valide en 1.x peut être hors du périmètre supporté par le 4.x, ce qui bloque le démarrage même avec un host.json parfait.
Faire correspondre Core Tools local et runtime cible. Une Core Tools v3 en local face à une app configurée en ~4 génère des comportements incohérents entre local et Azure.
Basculer directement en production. Sauter l’étape du slot de staging retire le principal filet de sécurité de toute cette procédure.

Dépannage : 8 problèmes fréquents et leurs solutions

“Value cannot be null. (Parameter ‘provider’)” au démarrage. Le champ extensionBundle est absent ou mal formé dans host.json. Reprenez le format de l’étape 4 exactement.
“func: command not found”. Core Tools n’est pas installé globalement, ou le PATH npm global n’est pas reconnu par le shell. Réinstallez avec npm install -g azure-functions-core-tools@4 --unsafe-perm true et ouvrez un nouveau terminal.
Une fonction ne se déclenche plus après migration. Le binding a changé de comportement par défaut entre le 1.x et le 4.x. Vérifiez la configuration explicite du binding concerné dans host.json.
Décalage de version détecté au démarrage local. Core Tools local en v3 face à une app ciblant ~4. Alignez les deux versions avant de continuer.
Azurite refuse de démarrer. Un port parmi 10000, 10001 ou 10002 est déjà utilisé par un autre processus. Libérez-le ou changez les ports par défaut via les options d’Azurite.
Déploiement réussi mais réponse HTTP 500. Le mauvais modèle .NET a été packagé (in-process au lieu d’isolated worker, ou l’inverse). Vérifiez le SDK déclaré dans le csproj.
Bindings Cosmos DB ou Event Hub cassés après migration. La plage de version de l’extension bundle est trop restrictive. Élargissez-la à [4.*, 5.0.0) comme dans l’exemple de l’étape 4.
“FUNCTIONS_WORKER_RUNTIME value is invalid”. La valeur déclarée (node, python, dotnet-isolated) ne correspond pas à la stack réellement déployée. Corrigez ce paramètre d’application avant tout nouveau déploiement.

Astuces avancées pour sécuriser votre migration

Une fois la bascule technique terminée, quelques pratiques supplémentaires réduisent le risque sur le long terme. Automatisez la vérification de version du runtime dans votre pipeline de livraison continue, plutôt que de la contrôler manuellement à chaque déploiement, sur le même principe de validation automatique que celui décrit dans notre tutoriel sur Azure Blob Storage pour les changements de configuration de stockage.

Pensez aussi à fixer la version du runtime dans votre infrastructure as code (Bicep ou Terraform) plutôt que dans la console Azure. Un paramètre FUNCTIONS_EXTENSION_VERSION défini en dur dans un fichier versionné évite les dérives de configuration entre environnements. Si votre organisation exploite un cluster Kubernetes en parallèle de ses Function Apps, notre guide sur AKS applique le même principe de versionnage explicite pour les composants critiques, et notre rubrique cloud regroupe l’ensemble de nos tutoriels sur ce type d’infrastructure.

Enfin, activez un déploiement progressif par pourcentage de trafic sur le slot de production après le swap, plutôt qu’une bascule à 100 % immédiate. Cette approche, comparable à celle utilisée pour les déploiements Cloud Run côté Google Cloud dans notre tutoriel dédié, limite l’impact d’une régression non détectée pendant les tests de staging à une fraction du trafic réel, le temps de confirmer que tout fonctionne comme prévu.

Mettez enfin en place une alerte Application Insights sur le taux d’erreur et la latence P95 de chaque Function App migrée, avec un seuil resserré pendant les deux premières semaines suivant la bascule. Une régression de performance liée à la migration se manifeste rarement dès la première heure : elle apparaît plus souvent après quelques jours, quand le trafic retrouve son profil habituel et que les caches applicatifs se sont reconstruits sur la nouvelle version.

Calendrier récapitulatif des échéances

Date	Échéance	Action recommandée
14 septembre 2026	Fin du support du runtime 1.x	Migrer toutes les apps 1.x vers le 4.x
30 septembre 2026	Arrêt d’exécution du runtime 3.x sur plan Linux Consumption	Prioriser ces apps en premier
10 novembre 2026	Fin du support du modèle in-process (.NET)	Basculer vers isolated worker

Ce calendrier serré explique pourquoi tant d’équipes en France et en Europe traitent cette migration comme un projet unique plutôt que trois chantiers distincts. Les mêmes commandes (host.json, extension bundle, slot de staging) servent aux trois échéances, ce qui limite le travail réel à une seule campagne de tests bien menée.

Aide-mémoire des commandes CLI utilisées dans ce tutoriel

Gardez ce tableau à portée de main pendant la migration. Il regroupe les commandes de chaque étape dans l’ordre où vous les exécuterez, pour éviter de remonter tout l’article à chaque fois que vous changez de terminal.

Objectif	Commande	Étape concernée
Vérifier la version de runtime d’une app	`az functionapp config appsettings list --query "[?name=='FUNCTIONS_EXTENSION_VERSION']"`	Étape 1
Installer Core Tools 4.x	`npm install -g azure-functions-core-tools@4 --unsafe-perm true`	Étape 2
Vérifier la version locale de Core Tools	`func --version`	Étape 2
Créer une branche de migration	`git checkout -b migration/runtime-4x`	Étape 3
Démarrer Azurite en local	`azurite --silent --location ./azurite-data`	Étape 9
Lancer l’application en local	`func start --verbose`	Étape 10
Créer un slot de staging	`az functionapp deployment slot create --slot staging`	Étape 11
Basculer en production	`az functionapp deployment slot swap --slot staging --target-slot production`	Étape 12

Ce que la migration change du point de vue sécurité et conformité

Migrer un runtime n’est pas qu’une question de compatibilité technique. Une application qui tourne encore sur un runtime en fin de support sort mécaniquement du périmètre des correctifs de sécurité de Microsoft, ce qui pose un problème concret pour toute entreprise soumise à des obligations de maintien en conditions de sécurité. Les équipes conformité commencent d’ailleurs à intégrer ce type d’échéance dans leurs audits internes, au même titre que les dates de fin de vie des systèmes d’exploitation ou des bibliothèques cryptographiques.

Concrètement, documentez la date de migration de chaque application dans votre registre d’actifs, avec la version de runtime cible et le responsable technique. Ce simple suivi facilite grandement les audits de sécurité périodiques et évite qu’une application isolée, oubliée d’un audit à l’autre, ne reste sur un runtime non supporté pendant des mois sans que personne ne s’en aperçoive. Pour les organisations qui gèrent plusieurs dizaines de Function Apps, un script d’inventaire automatisé (reprenant la commande de l’étape 1 en boucle sur tout l’abonnement) vaut largement l’heure de développement qu’il coûte.

Cette discipline de suivi rejoint un problème plus large que rencontrent aujourd’hui la plupart des équipes cloud en Europe : la multiplication des dates de fin de support sur des composants différents (runtimes, bibliothèques, images de base) rend le suivi manuel intenable au-delà d’une dizaine d’applications. Un tableau de bord centralisé, même simple, qui croise chaque application avec ses dates d’échéance critiques reste le moyen le plus fiable d’éviter la découverte tardive d’un composant hors support en pleine production.

Foire aux questions

Que se passe-t-il si je ne migre pas avant le 14 septembre 2026 ?
Votre application continuera probablement de tourner dans l’immédiat, mais elle ne recevra plus aucun correctif de sécurité ni mise à jour de Microsoft. En cas d’incident lié au runtime, aucun support officiel ne sera disponible, et toute vulnérabilité découverte après cette date sur le runtime 1.x restera non corrigée sur votre application tant qu’elle n’aura pas migré.

Le modèle in-process va-t-il complètement disparaître ?
Non, les applications existantes pourront continuer à s’exécuter après le 10 novembre 2026, mais sans support ni mise à jour de sécurité. Microsoft recommande une migration vers isolated worker pour toute app .NET encore active.

Puis-je migrer directement du 1.x vers isolated worker sans étape intermédiaire ?
Oui. Il n’est pas nécessaire de passer par le 3.x. La documentation officielle de migration part directement du 1.x pour rejoindre le 4.x, avec ou sans passage par isolated worker selon votre langage.

Azure Functions Core Tools 4.14.0 est-elle compatible avec un projet encore en 1.x localement ?
Non. Une fois Core Tools v4 installée, elle attend un host.json et une structure de projet conformes au 4.x. Migrez d’abord le projet, testez ensuite en local.

Le coût d’exécution change-t-il après la migration ?
Le passage au runtime 4.x ne modifie pas en soi le modèle de facturation du plan Consumption ou Premium. Les coûts peuvent varier si la migration s’accompagne d’un changement de plan d’hébergement ou d’une optimisation des temps d’exécution.

Comment savoir si une application est encore sur le runtime 1.x ?
Interrogez le paramètre FUNCTIONS_EXTENSION_VERSION avec la commande Azure CLI présentée à l’étape 1. Une valeur ~1 confirme que l’app tourne encore sur l’ancien runtime.

La migration nécessite-t-elle un arrêt de service ?
Non, si vous passez par un slot de staging et un swap, comme décrit aux étapes 11 et 12. Le swap entre slots est quasi instantané et ne provoque pas d’interruption perceptible côté utilisateur, à condition que le slot de staging ait été testé sous charge réelle au préalable et non simplement démarré puis basculé sans validation.

Faut-il migrer toutes les applications le même jour ?
Non, et ce n’est pas recommandé. Étalez la migration sur plusieurs semaines en commençant par les applications les moins critiques, pour valider votre méthode avant de l’appliquer aux applications qui touchent directement vos utilisateurs finaux.

Azure Functions : Migration 1.x vers 4.x en 12 Étapes [2026]