Quand on parlait d’Azure Container Apps il y a quelques années, le modèle était relativement simple.

J’ai un conteneur. Je veux exécuter une API, une application Web ou un microservice sans gérer Kubernetes.

Aujourd’hui, l’écosystème Azure Container Apps s’est considérablement enrichi.

Nous avons maintenant :

Azure Container Apps
Container Apps Jobs
Dynamic Sessions
Container Apps Sandboxes

À première vue, ces services peuvent sembler relativement proches.

Après tout, ils permettent tous d’exécuter des workloads conteneurisés dans l’écosystème Azure Container Apps.

Mais leur cycle de vie est complètement différent.

Et selon moi, c’est justement le meilleur moyen de choisir entre eux.

La première question que je me pose n’est donc plus seulement :

Quel conteneur dois-je exécuter ?

Mais plutôt :

Comment mon workload doit-il vivre ?

Doit-il rester disponible en permanence ?

Doit-il démarrer, effectuer une tâche puis s’arrêter ?

Ai-je besoin d’exécuter très rapidement du code dans un environnement isolé ?

Ou ai-je besoin d’un véritable environnement de calcul isolé dont je contrôle moi-même le cycle de vie et l’état ?

C’est principalement autour de ces questions que je distingue aujourd’hui les quatre modèles.

Azure Container Apps : mon application doit rester disponible

Commençons par le modèle que nous connaissons probablement le mieux.

Une Container App est particulièrement adaptée aux applications et services qui doivent rester disponibles pour recevoir du trafic ou traiter continuellement des événements.

On parle donc typiquement de :

Web Apps, APIs, microservices et services en arrière-plan.

Microsoft positionne d’ailleurs Container Apps pour les services de longue durée, alors que Jobs est destiné aux traitements qui doivent se terminer.

Prenons un exemple simple.

J’ai développé une API .NET :

POST /orders
GET  /orders/{id}
GET  /customers/{id}

Je ne sais pas exactement quand un utilisateur va appeler cette API.

Elle doit donc être disponible pour recevoir les requêtes.

C’est clairement une Container App.

Ce que j’aime particulièrement avec ce modèle

ACA prend en charge beaucoup de complexité que je devrais autrement gérer avec Kubernetes.

Je déploie mon image de conteneur et je peux ensuite configurer notamment :

l’Ingress;
le scaling;
les secrets;
les Managed Identities;
les variables d’environnement;
les certificats;
les révisions.

Le modèle de déploiement par revisions est d’ailleurs important.

Chaque modification significative du template d’une Container App peut produire une nouvelle révision. On peut ensuite fonctionner avec une seule révision active ou plusieurs simultanément.

Cela permet des stratégies intéressantes de déploiement et de gestion du trafic.

Quand je choisis une Container App

Je la privilégie donc pour :

une API REST ou GraphQL, une application Web, un backend mobile, un microservice, un serveur MCP, un service consommant continuellement des messages ou n’importe quel service qui doit rester disponible.

La logique est simple :

Mon application attend du travail.

Même si ACA peut faire du scale-to-zero dans certains scénarios, le concept reste celui d’une application disponible pour recevoir des requêtes ou événements.

Container Apps Jobs : mon traitement doit avoir une fin

Passons maintenant à Container Apps Jobs.

Ici, le modèle change complètement.

Un Job n’est pas conçu pour rester disponible.

Il est conçu pour :

démarrer → effectuer une tâche → terminer.

Microsoft définit justement les Jobs comme des tâches conteneurisées qui s’exécutent pendant une durée finie puis s’arrêtent.

Et cette distinction paraît simple, mais elle permet de résoudre beaucoup de cas d’utilisation.

Imaginez que tous les soirs à 2 h du matin, je dois générer les factures de mes clients.

Je lance mon conteneur.

Il récupère les données.

Il génère les factures.

Il les dépose dans un Storage.

Puis le processus se termine.

Je n’ai aucune raison de conserver ce workload actif pendant les 23 autres heures de la journée.

C’est exactement le genre de scénario pour lequel j’utiliserais un Container Apps Job.

Trois façons de démarrer un Job

J’aime particulièrement le fait que Microsoft propose trois modèles de déclenchement.

Un Job peut être Manual, donc lancé à la demande par le portail, Azure CLI ou une API.

Il peut être Scheduled, avec une planification de type cron.

Et il peut être Event-driven, donc démarrer en réponse à un événement, par exemple lorsqu’un message arrive dans une file.

Cela couvre énormément de scénarios.

Quelques exemples

Job planifié

Tous les jours à 02:00
        ↓
Container Apps Job
        ↓
Génération des rapports
        ↓
Fin

Job déclenché par événement

Azure Queue
    ↓
Messages disponibles
    ↓
Job
    ↓
Traite un lot
    ↓
Fin

Job manuel

Application
    ↓
Démarrer le Job
    ↓
Migration / import / traitement
    ↓
Fin

Microsoft cite également les self-hosted GitHub Actions runners et Azure Pipelines agents parmi les scénarios possibles pour les Event Jobs.

C’est un cas que je trouve particulièrement intéressant.

Container App ou Job ?

Pour moi, la distinction est généralement très simple.

Si mon processus ressemble à ceci :

while(true)
{
    attendreDuTravail();
}

je pense Container App.

S’il ressemble plutôt à ceci :

demarrer();
faireLeTravail();
terminer();

je pense Container Apps Job.

Dynamic Sessions : j’ai besoin d’exécuter du code maintenant

Avec les Dynamic Sessions, on entre dans un scénario complètement différent.

Ici, je ne cherche plus vraiment à déployer une application traditionnelle.

Je cherche plutôt à obtenir très rapidement un environnement d’exécution isolé.

Microsoft utilise pour cela des session pools contenant des environnements préchauffés.

Lorsqu’une requête arrive, une session peut être attribuée en quelques millisecondes plutôt que de devoir provisionner un nouvel environnement depuis zéro.

Et c’est particulièrement intéressant avec l’IA générative.

Imaginez une application utilisant un LLM.

L’utilisateur demande :

Analyse ce fichier CSV et calcule-moi les tendances des ventes des douze derniers mois.

Le LLM décide de générer un script Python.

Il faut maintenant exécuter ce code.

Je ne vais évidemment pas l’exécuter directement dans mon API.

Avec Dynamic Sessions, mon application peut demander un environnement isolé, y exécuter le code puis récupérer le résultat.

Utilisateur
    ↓
Application / Agent IA
    ↓
LLM génère du Python
    ↓
Dynamic Session
    ↓
Exécution isolée
    ↓
Résultat

C’est probablement l’un des cas d’utilisation les plus naturels.

Code Interpreter ou Custom Container

Il existe d’ailleurs deux approches intéressantes.

Le Code Interpreter fournit directement un environnement préparé pour l’exécution de code.

Mais si j’ai besoin de bibliothèques, binaires ou runtimes particuliers, je peux utiliser un Custom Container Session Pool et fournir ma propre image.

Cela ouvre beaucoup de possibilités.

Par exemple :

exécution de code généré par un LLM;
exécution sécurisée de code soumis par un utilisateur;
plateformes éducatives permettant aux étudiants d’exécuter du code;
tests rapides;
traitements interactifs;
workloads nécessitant une forte isolation entre utilisateurs.

Ce que j’apprécie ici : je ne gère pas réellement les sessions

C’est une différence fondamentale avec Sandboxes.

Mon application envoie une requête avec un identifiant de session.

Le pool attribue l’environnement.

Puis, après la période d’inactivité configurée, la session est automatiquement détruite.

Je ne veux pas gérer des environnements.

Je veux simplement exécuter quelque chose rapidement et de façon isolée.

C’est exactement là que Dynamic Sessions devient intéressant.

Sandboxes : je veux contrôler l’environnement lui-même

Puis arrivent les Azure Container Apps Sandboxes.

Et c’est probablement là que la distinction devient la plus subtile.

Sandboxes et Dynamic Sessions permettent tous les deux d’obtenir des environnements isolés.

Mais avec une Sandbox, l’environnement devient lui-même quelque chose que mon application peut gérer.

Je peux :

créer une Sandbox;
exécuter des commandes;
manipuler ses fichiers;
exposer des ports;
la suspendre;
la reprendre;
créer des snapshots;
monter du stockage;
contrôler son réseau;
puis finalement la supprimer.

Microsoft décrit justement Sandboxes comme du compute isolé programmable dont le développeur contrôle explicitement le cycle de vie.

Et cette différence change complètement les cas d’utilisation.

Exemple : un agent IA qui travaille pendant plusieurs heures

Imaginons un agent de développement logiciel.

Je lui demande :

Clone mon repository, analyse l’application, corrige les tests qui échouent et propose-moi un correctif.

L’agent crée une Sandbox.

Agent IA
   ↓
Create Sandbox
   ↓
git clone
   ↓
dotnet restore
   ↓
dotnet test
   ↓
Modification du code
   ↓
Tests

Mais après vingt minutes, l’agent attend une validation humaine.

Avec une Dynamic Session, je travaille avec un environnement éphémère dont le cycle de vie est géré par le pool.

Avec Sandboxes, je peux suspendre l’environnement.

Plus tard, je peux le reprendre avec son état.

Microsoft permet en effet de capturer dans un snapshot l’état de la mémoire et du disque puis de restaurer l’environnement ultérieurement.

Et là, on commence à avoir quelque chose de très différent d’une simple exécution de code.

On obtient véritablement un workspace de calcul programmable.

Les cas d’utilisation deviennent beaucoup plus larges

Je vois notamment Sandboxes pour :

les agents IA autonomes, qui ont besoin d’un workspace persistant entre plusieurs étapes;

les environnements de développement à la demande, où chaque développeur dispose de son environnement personnel;

les environnements interactifs par utilisateur, comme un IDE ou un terminal accessible depuis une application Web;

les plateformes SaaS multi-tenant, où chaque client doit disposer d’un environnement fortement isolé;

les environnements CI/CD éphémères, pour compiler et tester du code;

l’exécution de code non fiable, lorsque je veux contrôler précisément réseau, fichiers et cycle de vie.

Microsoft cite précisément les agents IA, environnements de développement, sessions utilisateur interactives, compute multi-tenant, workloads burst et pipelines CI/CD parmi les scénarios visés.

Dynamic Sessions ou Sandboxes ?

C’est probablement la comparaison qui mérite le plus d’attention.

Parce que les deux permettent d’exécuter du code dans des environnements fortement isolés et avec un démarrage très rapide.

Ma façon de les distinguer est la suivante.

Avec Dynamic Sessions, je veux :

une exécution isolée.

Avec Sandboxes, je veux :

un environnement isolé.

La nuance paraît faible, mais architecturalement elle est énorme.

Prenons deux exemples.

Analyse d’un fichier Excel par une IA

L’utilisateur envoie son fichier.

Le LLM génère du Python.

Le code s’exécute.

Je récupère les graphiques.

Terminé.

👉 Dynamic Sessions

Je n’ai aucune raison de conserver l’environnement.

Agent de développement logiciel

L’agent clone un repository.

Il installe des dépendances.

Il compile.

Il modifie plusieurs fichiers.

Il attend une décision humaine.

Il reprend son travail deux heures plus tard.

👉 Sandbox

Cette fois-ci, l’état de l’environnement fait partie du workflow.

Microsoft résume d’ailleurs cette différence de manière similaire : Dynamic Sessions fournit une expérience d’exécution managée et abstrait l’infrastructure, alors que Sandboxes donne un contrôle programmable sur l’environnement, son état et son cycle de vie.

Et Jobs vs Sandboxes ?

Autre comparaison intéressante.

Un pipeline CI/CD pourrait théoriquement fonctionner avec les deux.

Mais encore une fois, je regarderais le cycle de vie.

Mon pipeline démarre, compile mon application, lance mes tests puis disparaît ?

👉 Job

J’ai besoin de créer dynamiquement un environnement, installer différents outils, manipuler son filesystem, potentiellement le conserver entre plusieurs étapes et contrôler précisément son cycle de vie ?

👉 Sandbox

Ce n’est donc pas uniquement ce que fait le workload qui détermine le service.

C’est surtout la manière dont je veux gérer son environnement d’exécution.

Ma façon de choisir

Finalement, je trouve que la décision peut se résumer avec quatre questions.

Mon application doit-elle rester disponible ?

Oui → Container App

API, Web App, microservice, MCP Server ou worker continu.

Mon workload doit-il effectuer une tâche puis se terminer ?

Oui → Container Apps Job

Batch, tâche planifiée, traitement de queue, migration ou runner CI/CD.

Ai-je simplement besoin d’exécuter rapidement quelque chose dans un environnement isolé ?

Oui → Dynamic Sessions

Code généré par un LLM, Code Interpreter, code soumis par un utilisateur ou calcul interactif.

Ai-je besoin de contrôler l’environnement isolé lui-même et potentiellement conserver son état ?

Oui → Sandboxes

Agent IA, environnement de développement, workspace utilisateur, compute multi-tenant ou environnement programmable.

Tableau de synthèse

	Container Apps	Container Apps Jobs	Dynamic Sessions	Sandboxes
Modèle	Application	Tâche	Exécution isolée	Environnement isolé
Cycle de vie	Continu	Start → Run → Complete	Géré automatiquement par le pool	Contrôlé par l’application
Durée typique	Longue durée	Durée finie	Courte / interactive	Variable
État	Généralement externalisé	Stateless	Éphémère	Stateful possible
Démarrage	Scaling ACA	À la demande	Pool préchauffé, sub-seconde	Pool préchauffé, sub-seconde
Scale-to-zero	Oui selon configuration	Naturel entre exécutions	Géré par le pool	Oui lorsque stoppé
Révisions	Oui	Non	Non applicable	Non applicable
Déclenchement	HTTP / événements / scaling	Manuel / Schedule / Event	Appel HTTP au Session Pool	SDK / API / CLI
Gestion du lifecycle	ACA	ACA	Session Pool	Vous
Persistance de l’environnement	État externe recommandé	Non	Non	Oui : snapshots / volumes
Isolation code non fiable	Pas son objectif principal	Pas son objectif principal	Oui	Oui, forte isolation
Image personnalisée	Oui	Oui	Oui avec Custom Sessions	Oui, OCI
Cas idéal	API / Web App / microservice	Batch / cron / traitement ponctuel	Code Interpreter / LLM	Agent IA / workspace
Exemple	API .NET	Rapport financier nocturne	Exécuter du Python généré par GPT	Workspace d’un coding agent
Je le choisis quand…	« Mon application doit rester disponible »	« Ma tâche doit se terminer »	« Je veux exécuter quelque chose maintenant »	« Je veux contrôler un environnement isolé »

Ce que je trouve intéressant dans l’évolution d’Azure Container Apps

C’est probablement ce que je retiens le plus de l’évolution récente d’ACA.

Azure Container Apps n’est plus simplement un service pour héberger des conteneurs sans Kubernetes.

Il devient progressivement une véritable plateforme de compute serverless autour du conteneur.

Une application doit rester disponible ?

Container Apps.

Un traitement doit démarrer puis terminer ?

Jobs.

Un LLM doit exécuter quelques lignes de Python de façon sécurisée ?

Dynamic Sessions.

Un agent IA a besoin de son propre ordinateur temporaire, isolé et capable de conserver son état ?

Sandboxes.

Et je trouve cette évolution particulièrement intéressante avec l’arrivée des architectures basées sur les agents IA.

Nous ne construisons plus uniquement des applications qui attendent des utilisateurs.

Nous construisons également des systèmes capables de créer dynamiquement des environnements de calcul pour exécuter du travail au nom de ces utilisateurs.

Et c’est probablement là que la combinaison Container Apps + Jobs + Dynamic Sessions + Sandboxes devient réellement intéressante.

Les quatre technologies ne cherchent finalement pas à résoudre le même problème.

Elles permettent plutôt de choisir le bon cycle de vie du compute pour chaque partie de notre architecture.

Et pour moi, c’est probablement la meilleure façon de comprendre l’écosystème Azure Container Apps aujourd’hui.

Azure Container Apps, Jobs, Dynamic Sessions ou Sandboxes : lequel choisir ?