Azure Webjobs vs Azure Functions : comment choisir

ForumBot · Message par **ForumBot** » lun. mars 16, 2026 5:55 pm

Message par **ayi** » lun. mars 16, 2026 5:55 pm

Il y a quelques options ici au sein d’App Service. Je n’aborderai pas Logic Apps ou Azure Automation, qui touchent également à ce domaine.

Azure WebJobs

Cet article est honnêtement la meilleure explication, mais je vais résumer ici.

WebJobs à la demande, aussi appelés WebJobs planifiés ou WebJobs déclenchés

Les WebJobs déclenchés sont des WebJobs qui s’exécutent une seule fois lorsqu’une URL est appelée ou lorsque la propriété schedule est présente dans schedule.job. Les WebJobs planifiés sont simplement des WebJobs pour lesquels un job Azure Scheduler a été créé pour appeler notre URL selon un planning, mais nous prenons également en charge la propriété schedule, comme mentionné précédemment.

Résumé :

- Exécutable/Script à la demande

- Exécutions planifiées

- Doivent être déclenchés via le point de terminaison .scm

- La mise à l’échelle est manuelle

- Une VM est toujours nécessaire

WebJobs continus (sans SDK)

Ces jobs s’exécutent en permanence et nous les relançons quand ils plantent. Vous devez activer Always On pour que ceux-ci fonctionnent, ce qui signifie les exécuter au minimum dans le niveau Basic et au-dessus.

Résumé :

- Exécutable/Script toujours en cours d’exécution

- Nécessite Always On - niveau Basic et au-dessus

- Une VM est toujours nécessaire

WebJobs continus avec le SDK WebJobs

Ce ne sont rien de particulier du point de vue de la fonctionnalité “WebJobs”. Essentiellement, nous avons écrit ce SDK génial ciblant les WebJobs qui vous permet d’exécuter du code basé sur des déclencheurs simples. J’en parlerai davantage plus tard.

Résumé :

- Exécutable/Script toujours en cours d’exécution

- Journalisation/tableau de bord plus riches

- Déclencheurs pris en charge avec les tâches de longue durée

- Nécessite Always On - niveau Basic et au-dessus

- La mise à l’échelle nécessite une configuration manuelle

- Le démarrage peut être un peu fastidieux

- Une VM est toujours nécessaire

SDK Azure WebJobs

Le SDK Azure WebJobs est un SDK complètement séparé de la fonctionnalité plateforme WebJobs. Il est conçu pour être exécuté dans un WebJob, mais peut en réalité être exécuté n’importe où. Nous avons des clients qui l’exécutent

(Réponse tronquée)

AyiNEDJIMI · Message par **AyiNEDJIMI** » mar. mars 17, 2026 6:22 pm

Bonjour,

Le choix entre Azure WebJobs et Azure Functions est une question que beaucoup d’architectes et développeurs se posent lors de la conception d’une solution Azure. Ces deux services permettent d’exécuter du code en arrière-plan, mais ils répondent à des besoins différents. Je vais vous fournir une analyse complète pour vous aider à faire le bon choix.

Vue d’ensemble des deux services

Azure WebJobs

Les WebJobs sont une fonctionnalité d’Azure App Service qui permet d’exécuter des programmes ou des scripts en arrière-plan dans le même contexte qu’une application web App Service. Ils partagent les ressources de l’App Service Plan associé.

Caractéristiques principales :

Intégrés à App Service (même plan, même VM)

Peuvent être continus (s’exécutent en permanence) ou déclenchés (à la demande ou selon un planning)

Supportent de nombreux types de fichiers : .exe, .cmd, .bat, .sh, .php, .py, .js, .jar

Peuvent utiliser le SDK WebJobs pour une intégration avancée avec Azure Storage

Azure Functions

Azure Functions est un service de calcul serverless indépendant qui exécute du code en réponse à des événements, sans gestion de serveur. Il facture uniquement le temps d’exécution effectif (en mode Consumption).

Caractéristiques principales :

Modèle serverless ou dédié (Elastic Premium, Dedicated Plan)

Large éventail de déclencheurs (HTTP, Timer, Queue, Blob, Event Hub, Service Bus, Cosmos DB, etc.)

Plusieurs langages supportés : C#, JavaScript/TypeScript, Python, Java, PowerShell, Go (custom handler)

Mise à l’échelle automatique et élastique

Modèle de facturation à l’exécution (Consumption Plan)

Tableau comparatif détaillé

Critère	Azure WebJobs	Azure Functions
Modèle d’hébergement	Intégré à App Service	Indépendant (serverless ou plan dédié)
Facturation	Inclus dans l’App Service Plan	À l’exécution (Consumption) ou plan dédié
Mise à l’échelle	Manuelle (scale out App Service)	Automatique et élastique
Déclencheurs	Timer, continu, manuel	20+ déclencheurs natifs
Langages	Tout exécutable, SDK C#/Node	C#, JS/TS, Python, Java, PowerShell, Go
Durée max d’exécution	Illimitée	5 min (Consumption), 10 min extensible, illimité (Premium/Dedicated)
Accès au système de fichiers	Oui (partage App Service)	Limité (temporaire)
Monitoring	Application Insights (basique)	Application Insights (avancé, intégré)
CI/CD	Via App Service deployment	Via Azure DevOps, GitHub Actions natif
Local development	Via WebJobs SDK	Via Azure Functions Core Tools
Orchestration	Non	Oui (Durable Functions)
Cold start	Non (si App Service actif)	Oui (Consumption Plan)
Maturité	Stable, maintenance uniquement	Actif, nouvelles fonctionnalités régulières

Quand choisir Azure WebJobs ?

Cas d’usage favorables aux WebJobs

1. Vous avez déjà une App Service existante

Si votre application web tourne sur un App Service Plan, les WebJobs sont une extension naturelle sans coût supplémentaire :

// Exemple de WebJob avec SDK - traitement de messages Queue
public class Functions
{
    public static async Task ProcessQueueMessage(
        [QueueTrigger("maqueue")] string message,
        ILogger logger)
    {
        logger.LogInformation($"Message reçu : {message}");
        // Traitement du message
        await TraiterMessage(message);
    }
}

2. Tâches de longue durée nécessitant une exécution continue

Les WebJobs continus s’exécutent en permanence sans limite de temps, idéal pour :

Les listeners de files d’attente avec faible latence

Les processus de synchronisation permanents

Les tâches de monitoring continu

3. Accès nécessaire au système de fichiers de l’App Service

Les WebJobs partagent le système de fichiers avec l’application web parente, permettant d’accéder aux mêmes fichiers et répertoires.

4. Migration d’applications existantes

Si vous migrez une application .NET Framework legacy avec des traitements en arrière-plan, les WebJobs offrent une voie de migration simple.

Quand choisir Azure Functions ?

Cas d’usage favorables aux Functions

1. Architecture serverless et microservices

Pour des architectures découplées et event-driven :

// Azure Function avec Timer Trigger
[FunctionName("TraitementNocturne")]
public static async Task Run(
    [TimerTrigger("0 0 2 * * *")] TimerInfo myTimer,
    ILogger log,
    [CosmosDB(
        databaseName: "MaBDD",
        collectionName: "Commandes",
        ConnectionStringSetting = "CosmosDBConnection")] IAsyncCollector<dynamic> outputDocument)
{
    log.LogInformation($"Traitement nocturne démarré : {DateTime.Now}");

    var commandes = await RecupererCommandesNonTraitees();
    foreach (var commande in commandes)
    {
        await outputDocument.AddAsync(new { id = commande.Id, statut = "Traité" });
    }
}

2. Réponse à des événements multiples et variés

Azure Functions supporte nativement plus de 20 types de déclencheurs :

// Function déclenchée par un message Service Bus
[FunctionName("TraiterCommande")]
public static async Task Run(
    [ServiceBusTrigger("commandes", Connection = "ServiceBusConnection")] string message,
    [Table("CommandesTable", Connection = "StorageConnection")] CloudTable table,
    ILogger log)
{
    var commande = JsonConvert.DeserializeObject<Commande>(message);
    // Traitement...
}

3. Optimisation des coûts avec une charge variable

Le Consumption Plan d’Azure Functions inclut 1 million d’exécutions gratuites par mois et ne facture que ce qui est consommé :

Coût = (Nombre d'exécutions × 0,20 €/million) + (GB-secondes × 0,000016 €/GB-s)

4. Orchestration de workflows complexes avec Durable Functions

// Orchestrateur Durable Functions
[FunctionName("OrchestrateurCommande")]
public static async Task<List<string>> RunOrchestrator(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var outputs = new List<string>();

    // Exécution parallèle
    var tache1 = context.CallActivityAsync<string>("ValiderPaiement", "commande-123");
    var tache2 = context.CallActivityAsync<string>("VerifierStock", "commande-123");

    await Task.WhenAll(tache1, tache2);

    outputs.Add(await tache1);
    outputs.Add(await tache2);

    // Puis exécution séquentielle
    outputs.Add(await context.CallActivityAsync<string>("ExpedierCommande", "commande-123"));

    return outputs;
}

5. Exposition d’API légères

// HTTP Trigger pour une API simple
[FunctionName("GetProduit")]
public static async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "get", Route = "produits/{id}")] HttpRequest req,
    string id,
    ILogger log)
{
    var produit = await _repository.GetProduitAsync(id);
    return produit != null
        ? new OkObjectResult(produit)
        : new NotFoundResult();
}

Arbre de décision

Pour vous aider à choisir rapidement, voici un arbre de décision :

Avez-vous déjà un App Service Plan ?
├── OUI → Votre tâche dure plus de 10 minutes ou est continue ?
│   ├── OUI → WebJobs
│   └── NON → Les deux conviennent, préférez Functions pour l'évolutivité
└── NON → Vous avez besoin de serverless (pas de gestion serveur) ?
    ├── OUI → Azure Functions (Consumption Plan)
    └── NON → Votre charge est imprévisible ?
        ├── OUI → Azure Functions (Elastic Premium)
        └── NON → Évaluez App Service + WebJobs vs Functions Dedicated

Migration de WebJobs vers Azure Functions

Si vous souhaitez migrer des WebJobs existants vers Functions :

# Installer Azure Functions Core Tools
npm install -g azure-functions-core-tools@4

# Créer un nouveau projet Functions
func init MonProjetFunctions --dotnet

# Ajouter une fonction depuis un template
func new --name MonTraitement --template "Timer trigger"

# Tester localement
func start

Le WebJobs SDK est d’ailleurs la base sur laquelle Azure Functions a été construit, ce qui facilite la migration du code métier.

Recommandation finale

Choisissez WebJobs si vous avez un App Service existant, besoin d’exécution continue, ou contraintes de migration legacy.

Choisissez Azure Functions pour tout nouveau développement, les architectures event-driven, la mise à l’échelle automatique et l’optimisation des coûts.

Dans la majorité des projets nouveaux, Azure Functions est le choix recommandé par Microsoft et offre une feuille de route produit plus active.

Si vous nous donnez plus de détails sur votre cas d’usage spécifique (type de traitement, fréquence, durée, contraintes d’infrastructure), je pourrai affiner cette recommandation et vous aider à concevoir l’architecture optimale.

Forum communauté Microsoft