Compute — où s'exécutent les traitements, et pourquoi le batch est isolé

Vous êtes ici : Comprendre — les fondations : où s’exécutent les traitements de la suite. Où s’exécute le traitement — et pourquoi on ne le mélange pas. Lecture 8 min. Audience : devs, data engineers, auditeurs. Date : 2026-07-06 | Version : 1.0

Le principe central — deux profils de charge opposés

Une app web (Console UG, GS-Inventaire…) doit être allumée et réactive en permanence : plein de petites requêtes, en millisecondes. Un traitement par lots (l’ETL SOFI) est l’inverse : il dort presque tout le temps, puis consomme énormément de ressources pendant quelques minutes.

Les mélanger sur la même machine, c’est laisser le batch étouffer le serveur web pendant son pic. La règle de la plateforme : on ne fait pas tourner un batch dans un serveur web.

TL;DR

Question	Réponse	Détail
Où tournent les apps web ?	Sur App Service, un plan partagé allumé 24/7	hub · admin · ug · inv · gest · mcp · api-portail
Où tourne l’ETL ?	Sur un worker Container Apps Job dédié, isolé et éphémère	gs-etl-worker (déclenché par file + par horaire)
Pourquoi les séparer ?	Deux profils de charge opposés — le pic du batch ne doit pas toucher le web	Isolation des charges
C’est une autre souscription ?	Non — même souscription, même resource group, même VNet, même base	Container Apps = un type de ressource de plus, pas un ailleurs
Ça coûte quoi ?	App Service = loyer fixe ; le worker = à l’usage (0 $ au repos)	~12 min par sync facturées, pas 24/7
Et une future charge ?	« Doit-elle être allumée en permanence ? » Oui → App Service. Non → Job	Voir la règle de décision plus bas

La carte compute

L’image juste n’est pas « tout au même endroit », mais deux machines séparées. Les apps web vivent sur un plan partagé et toujours allumé. Le traitement lourd vit dans une machine jetable qui naît quand on la déclenche, brasse ses données, puis disparaît. L’app admin ne fait plus l’ETL elle-même : elle dépose un message dans une file, et le worker prend le relais dans son coin.

Le web et le batch tournent sur deux machines distinctes. L’app admin déclenche l’ETL par un simple message ; le worker fait le travail lourd, isolé.

Pourquoi le batch sort du web

Historiquement, l’ETL tournait dans l’application admin (un backend web). Deux conséquences, longtemps invisibles :

1. Le démarrage de l’app s’alourdit. Les bibliothèques nécessaires au traitement gonflent le temps de démarrage du serveur web.
2. Les voisines partagent le sort. Sur un plan App Service partagé, quand une app sature la machine, elle peut entraîner les autres avec elle.

Le couplage a un coût réel

En juillet 2026, un incident de production a démontré ce couplage : un traitement ETL logé dans une application web a saturé la machine pendant un recyclage, et a entraîné des applications voisines dans une panne prolongée. La sortie de l’ETL vers un worker isolé supprime cette classe de panne à la racine.

Sortir le traitement vers un Container Apps Job règle les deux points d’un coup : le worker vit dans sa propre machine jetable — s’il échoue, il échoue seul —, et le démarrage du web redevient léger, puisque admin ne fait plus que déposer un message avant de retourner à son travail de site web.

Le modèle de facturation

C’est la source de confusion classique : deux modèles opposés cohabitent. La forme de la charge dicte la forme de la facture :

Deux profils de charge opposés : une bande continue contre un pic nocturne. L app web paie son loyer 24/7 ; le batch ne paie que ses ~12 minutes.

App Service — loyer fixe

Une machine qui tourne 24/7. Tu paies le même prix qu’elle soit occupée ou endormie. En échange : toujours prête à répondre. C’est le bon modèle pour une app web.

Container Apps Job — à l'usage

Une machine jetable, facturée au temps d’exécution réel. 0 $ quand elle dort. L’ETL facturé ~12 min par nuit, au lieu d’alourdir une machine payée de toute façon. C’est le bon modèle pour un batch.

Note

« C’est sur notre App Service » est faux pour le worker — et c’est là tout l’intérêt. Tout le gain de l’isolation vient précisément du fait que le worker n’y est pas. Même souscription, même VNet, même base : seule la machine d’exécution diffère.

La règle de décision

Avant de créer une nouvelle charge de travail, une seule question :

Doit-elle être allumée et prête à répondre en permanence ?

• Oui → App Service. C’est une app web ou une API interactive.
• Non — elle réagit à un déclencheur (file, horaire, événement) et fait un travail borné dans le temps → Container Apps Job. Éphémère, à l’usage, avec sa propre identité (jamais celle d’une app web).

Situation	Cible
API REST interne consommée par le front	App Service
Sync / import / export de données volumineuses	Container Apps Job
Petite tâche déclenchée, < quelques secondes	Job (ou Azure Function si vraiment minime)
Webhook qui répond vite puis travaille en arrière-plan	App Service (accusé) + Job (travail lourd)

En cas de doute : si la charge peut faire un pic de ressources ou tourner plusieurs minutes, elle ne va pas dans une app web.

Trajectoire

Le modèle actuel — App Service pour le web, Container Apps Job pour le batch — est un choix propre, défendable devant n’importe quel architecte. Ce n’est pas le seul possible : une version « un seul modèle partout » mettrait aussi les apps web en conteneurs, pour n’opérer qu’un seul runtime. C’est une trajectoire, pas un prérequis — on l’envisagera le jour où un bénéfice concret le justifie (opération unifiée, coût, scaling). Le worker ETL est le premier pas dans cette direction : on apprend Container Apps sur une charge à faible risque avant d’envisager plus large.

Pour aller plus loin

• Architecture de données — où vivent et transitent les données (la sœur de cette page).
• Architecture C4 — la vue d’ensemble des composants.