Ce qui change
Le développement agent adoptable de ce cycle est un runtime, pas un modèle. Pendant que GPT-5.6 reste en preview limitée à une vingtaine de partenaires et que Gemini 3.5 Pro demeure en accès restreint, les Hosted Agents de Microsoft Foundry (Foundry Agent Service) forment un runtime managé et agnostique du framework : ils exécutent votre propre code d’agent, quel que soit le framework, sur l’infrastructure Microsoft 12. Il est appelable dès aujourd’hui en preview publique sur 20 régions Azure, et Microsoft vise la disponibilité générale (GA) pour fin juin 2026 1 ; la page de concept Microsoft Learn, mise à jour le 25-06-2026, le qualifie toujours de « currently in preview » 2 : le cadrage honnête est donc preview maintenant, pas GA livrée. Le fait central est à double source : documentation Microsoft et article indépendant d’InfoQ décrivent des sessions sandboxées managées, avec état et accès au système de fichiers, plusieurs frameworks, et une API Responses avec état doublée d’un protocole Invocations plus léger 23.
La couche runtime
À mon sens, la pile agent se scinde en trois couches - le modèle, le framework et le runtime - et le runtime (là où l’agent s’exécute réellement : isolation, identité, état persisté, montée en charge) devient un produit que l’on loue plutôt qu’on assemble à la main. La substance technique suit. Chaque session tourne dans son propre sandbox isolé au niveau VM ou hyperviseur, doté d’un $HOME persistant, ce qui autorise le scale-to-zero avec reprise d’état 12. Chaque agent déployé reçoit son propre Microsoft Entra ID (identité d’agent) et un endpoint dédié au déploiement 12. Et le déploiement part du source, sans conteneur à construire soi-même 2 :
# Déploie le source de l'agent directement (aucun empaquetage de conteneur requis)
azd deploy
# Chaque agent déployé reçoit automatiquement un Microsoft Entra ID (identité d'agent)
# et un endpoint dédié au moment du déploiement.
# Protocoles exposés : Responses (compatible OpenAI, /responses), Invocations (JSON).
Les limites opérationnelles
Chiffres documentés par Microsoft seul (docs Learn), non corroborés de façon indépendante ; à prendre comme point de départ, à vérifier sous votre propre charge.
| Limite ou paramètre | Valeur documentée |
|---|---|
| Délai d’inactivité | 15 minutes 2 |
| Durée de vie de session | supprimée après 30 jours d’inactivité 2 |
| Quota par défaut | 50 sessions actives simultanées par abonnement et par région 2 |
| Tailles de sandbox | 0,5/1/2 vCPU (1/2/4 Gio) 2 |
| Disque par session | jusqu’à 20 Gio (~20% réservés au système) 2 |
Impact pour une équipe
Si vous assemblez aujourd’hui votre propre hébergement d’agents (isolation, identité, état, montée en charge), c’est cette couche que le service remplace, et contrairement aux modèles sous accès restreint de ce cycle, il est appelable maintenant : il mérite un essai ciblé. Le piège tient à l’endroit où se déplace le verrouillage. Le code reste réellement agnostique du framework (Agent Framework, LangGraph, Semantic Kernel ou du code Python/C# maison), mais le runtime et l’identité sont arrimés à Azure et à Microsoft Entra : le verrou passe de votre code à votre runtime et à votre IAM. C’est là la vraie décision d’architecture, pas la démo. Deux points à surveiller avant tout déploiement : c’est une preview, dont la GA n’est visée que pour fin juin 2026, donc n’y adossez pas de SLA de production ; et comme la facturation est par session, on dimensionne les sandbox d’abord, pas après.