En bref : Microsoft Foundry Agent Service est passé en disponibilité générale début juillet 2026. Le service propose un runtime managé pour déployer des agents IA sur Azure sans gérer de serveurs, avec une isolation par session dans des sandboxes VM dédiées, et un support agnostique des principaux frameworks d'agents : Microsoft Agent Framework 1.0 (qui unifie AutoGen et Semantic Kernel), LangGraph, GitHub Copilot SDK. Le déploiement se fait via azd deploy en quelques commandes.
Pour les entreprises françaises déjà sur Azure — la majorité des ETI et grandes PME — c'est la voie d'entrée la plus directe vers les agents IA en production, avec les garanties de conformité Azure déjà en place : résidence des données UE, RGPD, certifications SOC 2 et ISO 27001. Cet article décrypte ce que le service apporte réellement, ses différences avec ce qui existait avant, et trois cas d'usage concrets pour évaluer si ça répond à votre contexte.
Qu'est-ce que Foundry Agent Service ?
Foundry Agent Service est un composant de la plateforme Azure AI Foundry — le hub unifié de Microsoft pour les projets IA en production, anciennement Azure AI Studio. Il répond à un problème précis que rencontrent les équipes qui ont prototypé des agents IA : comment passer du Jupyter notebook ou du script Python local à un service en production scalable, sécurisé et observable ?
Avant Foundry Agent Service, les options étaient soit de déployer son agent sur un App Service ou un Azure Container App — ce qui demande de gérer l'infrastructure, la scalabilité, la persistance de l'état, les timeouts — soit d'utiliser un service managé propriétaire moins flexible. Foundry Agent Service comble ce fossé en proposant un runtime d'exécution clé-en-main.
Ce que le service fournit concrètement
- Un runtime d'exécution managé : l'infrastructure sous-jacente (VM, réseau, stockage temporaire, scaling) est gérée par Microsoft. L'équipe de développement se concentre sur la logique métier de l'agent.
- Une isolation par session : chaque session d'agent s'exécute dans sa propre sandbox VM dédiée, avec son propre espace de calcul, de mémoire et de filesystem. Deux sessions parallèles d'un même agent sont complètement isolées l'une de l'autre.
- Le support des agents à long terme : contrairement à des architectures stateless qui traitent une requête et terminent, Foundry Agent Service supporte nativement les agents dits hosted agents qui maintiennent un état persistant, accèdent à un filesystem durable et peuvent s'exécuter sur des périodes longues.
- Les routines (en preview publique) : un mécanisme pour exécuter n'importe quel agent sur un timer ou un schedule, sans infrastructure Cron externe.
L'isolation VM par session : pourquoi c'est structurant
L'isolation VM par session est probablement la décision d'architecture la plus importante de Foundry Agent Service. Elle répond directement aux risques de sécurité et de confidentialité qui bloquent les déploiements en production.
Dans une architecture naïve, plusieurs sessions d'un même agent partagent le même processus, la même mémoire, voire le même filesystem temporaire. Le risque : une session compromise (par une prompt injection dans un document traité, par exemple) peut potentiellement accéder aux données d'une autre session. C'est un vecteur d'attaque réel, documenté par les équipes de sécurité spécialisées en IA agentique.
Avec l'isolation VM, chaque session possède son propre noyau, sa propre mémoire et son propre filesystem. Une session malveillante ne peut pas atteindre les ressources d'une autre session. C'est l'équivalent de ce que les hyperviseurs font pour les machines virtuelles, appliqué au niveau des sessions d'agents IA.
Concrètement pour une ETI, cela signifie que vous pouvez servir plusieurs clients ou départements depuis la même infrastructure d'agent, sans risque de fuite de données entre sessions. C'est un prérequis pour les usages en traitement documentaire confidentiel, en assistance juridique, ou en tout contexte où les données d'un utilisateur ne doivent jamais être exposées à un autre. Pour les projets d'outil interne sur mesure traitant des données sensibles, cette garantie change l'analyse de risque.
La contrepartie est un overhead à l'initialisation de session : démarrer une sandbox VM prend de l'ordre de quelques secondes, ce qui est acceptable pour des tâches de traitement (analyse de documents, workflows batch) mais à prendre en compte pour des usages temps réel nécessitant des sessions très fréquentes et courtes.
Frameworks supportés : LangGraph, AutoGen, Semantic Kernel
Foundry Agent Service est agnostique de framework. Il ne vous force pas à utiliser un SDK propriétaire Microsoft : vous pouvez déployer un agent écrit avec LangGraph, AutoGen, Semantic Kernel, ou le nouveau Microsoft Agent Framework 1.0 (qui unifie AutoGen et Semantic Kernel), sans réécriture.
Microsoft Agent Framework 1.0
Passé en disponibilité générale le 2 avril 2026, Microsoft Agent Framework 1.0 est disponible pour .NET et Python. Il unifie AutoGen (orchestration multi-agents) et Semantic Kernel (intégration LLM + tools) sous une interface commune. Pour les équipes qui avaient déjà du code AutoGen ou Semantic Kernel, la migration est documentée et progressive — les deux bibliothèques restent utilisables en tant que sous-couches.
LangGraph
La compatibilité LangGraph est stratégiquement importante : LangGraph est l'une des bibliothèques d'orchestration d'agents les plus utilisées dans l'écosystème Python, notamment pour les architectures à états (stateful agents) et les workflows multi-étapes complexes. Les équipes qui ont déjà prototypé des agents avec LangGraph peuvent déployer sur Foundry Agent Service sans modifier leur code d'orchestration. C'est un argument fort pour réduire le time-to-production.
GitHub Copilot SDK
Pour les équipes qui construisent des extensions d'agents dans l'écosystème GitHub — code review automatisé, assistants de CI/CD, agents de documentation — le GitHub Copilot SDK est également supporté nativement.
Modèles disponibles et point de vigilance
Foundry Agent Service donne accès à l'ensemble du catalogue Azure AI Foundry : GPT-5, GPT-5.6, Mistral Large 2, Llama 4 en open source, et les modèles Phi de Microsoft. Claude d'Anthropic n'est pas directement disponible via Foundry Agent Service — il reste accessible via AWS Bedrock ou l'API Anthropic directe. C'est un point d'attention pour les équipes qui souhaitent utiliser Claude dans un environnement Azure.
Trois cas d'usage concrets pour une ETI
Voici trois situations réelles où Foundry Agent Service apporte une valeur concrète par rapport aux alternatives disponibles avant juillet 2026.
1. Agent de traitement documentaire en batch
Une ETI dans les services financiers ou juridiques reçoit chaque jour des dizaines de contrats, factures ou rapports à analyser. Un agent LangGraph qui lit chaque document, extrait les données structurées, vérifie la conformité et génère un résumé peut être déployé sur Foundry Agent Service en mode routine : il s'exécute automatiquement à heure fixe, dans des sandboxes isolées par document, avec les résultats stockés dans Azure Blob Storage.
Avant Foundry Agent Service, ce type de workflow nécessitait soit un Cron job sur une VM Azure (gestion de l'infrastructure, monitoring, redémarrage en cas d'échec), soit une Azure Logic App (moins flexible pour la logique Python complexe). La routine Foundry Agent Service simplifie considérablement ce schéma.
2. Assistant interne à état persistant
Un agent d'assistance interne qui aide les équipes support à répondre aux questions clients en interrogeant la base de connaissances, l'historique CRM et la documentation produit. Avec les hosted agents à état persistant, l'agent peut maintenir le contexte d'une conversation sur plusieurs heures ou jours, accéder à un filesystem pour mettre en cache des données fréquentes, et utiliser un planning multi-étapes pour les requêtes complexes. L'isolation VM garantit que les conversations de deux agents simultanés sont cloisonnées. Ce type d'usage s'inscrit directement dans notre approche de l'automatisation métier.
3. Pipeline d'enrichissement de données CRM
Un agent AutoGen qui, déclenché par un webhook Salesforce lors de la création d'un nouveau lead, enrichit automatiquement la fiche avec des données externes, génère un email de qualification personnalisé et crée une tâche de suivi dans l'agenda du commercial. Ce workflow multi-outils — typiquement difficile à orchestrer de façon fiable — devient gérable avec le runtime Foundry Agent Service, qui gère les timeouts, les re-tentatives et la journalisation des appels d'outils.
Démarrage pratique sur Azure
Conditions préalables : un abonnement Azure actif avec accès à Azure AI Foundry, et Azure Developer CLI (azd) installé. Le service est disponible dans les régions Azure majeures, y compris les régions UE.
Les grandes étapes
- Créer un projet Azure AI Foundry dans le portail Azure ou via la CLI. Le projet regroupe toutes les ressources (modèles, agents, connexions) de votre application.
- Écrire l'agent dans le framework de votre choix (Microsoft Agent Framework, LangGraph, etc.) en utilisant le SDK Azure AI Foundry correspondant.
- Configurer le déploiement dans
azure.yaml— le fichier de configuration d'azd— en déclarant les ressources nécessaires. - Déployer avec
azd deploy. L'outil provisionne automatiquement l'infrastructure (Foundry Agent Service, identités managées, connexions aux services Azure) et déploie votre code. - Monitorer via le Foundry Portal ou Azure Monitor. Foundry Agent Service expose des traces par session, des métriques de latence et d'utilisation des tokens.
Ce que vous évitez de gérer
- Provisionnement et scaling des VM
- Configuration des politiques réseau et des identités managées
- Gestion des timeouts et des re-tentatives sur les appels d'outils
- Mise en place du monitoring et de l'observabilité
Pour les organisations qui ont déjà un tenant Azure configuré avec les politiques de sécurité, les groupes AD et les contrôles d'accès en place, Foundry Agent Service hérite directement de tout cet environnement. Si vous souhaitez évaluer si cette architecture correspond à votre contexte, notre équipe peut vous accompagner dans le cadrage — contactez-nous.
FAQ — Microsoft Foundry Agent Service passe en disponibilité générale : sandboxes VM par session, LangGraph et AutoGen natifs — de la preuve de concept à la production
Foundry Agent Service est-il disponible dans les régions Azure Europe ?
Oui. Microsoft Foundry Agent Service est disponible dans les régions Azure UE majeures au moment de sa disponibilité générale en juillet 2026. Pour une utilisation en conformité RGPD avec résidence des données en Europe, il est recommandé de choisir explicitement une région UE (West Europe, North Europe, France Central) dans la configuration du projet Azure AI Foundry. Les données de session restent dans la région choisie et ne transitent pas vers des régions US par défaut.
Est-il possible d'utiliser Claude d'Anthropic avec Foundry Agent Service ?
Pas directement. Foundry Agent Service est couplé au catalogue de modèles d'Azure AI Foundry, qui inclut les modèles OpenAI (GPT-5, GPT-5.6), Mistral, Llama 4 et les modèles Phi de Microsoft. Claude d'Anthropic n'est pas disponible dans ce catalogue. Il reste accessible via AWS Bedrock (avec la région Francfort pour l'UE) ou l'API Anthropic directe. Si votre architecture nécessite Claude, une approche hybride est possible : Foundry Agent Service pour l'orchestration et l'infrastructure, et des appels vers une API Claude externe pour les étapes de raisonnement spécifiques.
Quelle est la différence entre Foundry Agent Service et Azure Container Apps pour héberger un agent ?
Azure Container Apps est un service de conteneurs managés généraliste : vous dockerisez votre agent, vous définissez les règles de scaling, vous gérez vous-même l'état, les timeouts et la persistance. Foundry Agent Service est un runtime spécialisé pour les agents IA : il gère nativement l'isolation par session, la persistance d'état pour les agents à long terme, les routines sur timer, et l'intégration avec le catalogue de modèles Azure AI Foundry. Pour un agent simple ou stateless, Container Apps reste une option valide et plus flexible. Pour des agents complexes avec état persistant et besoin d'isolation forte, Foundry Agent Service réduit significativement la charge d'infrastructure.
Le service est-il compatible avec des agents construits avec LangChain classique ?
LangGraph est explicitement supporté dans le catalogue officiel de Foundry Agent Service. LangChain classique n'est pas nommé dans la documentation officielle de GA, mais dans la mesure où LangGraph est construit sur LangChain, les agents LangChain sans orchestration de graphe peuvent généralement être déployés. Il est recommandé de tester sur un cas concret avant de s'engager sur cette architecture, ou de migrer vers LangGraph si les fonctionnalités d'orchestration à états sont pertinentes pour votre cas d'usage.
Y a-t-il un coût spécifique pour Foundry Agent Service au-delà des coûts de modèles ?
Microsoft facture Foundry Agent Service sur la base du temps de session et des ressources compute utilisées, en plus des coûts de tokens pour les modèles. Le modèle tarifaire exact est disponible dans la page de tarification Azure AI Foundry. Pour une estimation réaliste, il est recommandé de définir le nombre de sessions concurrentes attendues, la durée moyenne de chaque session, et le volume de tokens — les trois variables qui pilotent la facture totale.