Foundry Toolboxes : Un seul endpoint pour tous les outils de vos agents

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Voici un problème qui semble banal jusqu’à ce qu’on le vive : l’organisation construit plusieurs agents IA, chacun nécessite des outils, et chaque équipe les reconfigure à partir de zéro. La même intégration de recherche web, la même config Azure AI Search, la même connexion au serveur MCP GitHub — mais dans un autre dépôt, par une autre équipe, avec d’autres credentials et sans gouvernance partagée.

Microsoft Foundry vient de lancer Toolboxes en preview publique, et c’est une réponse directe à ce problème.

Qu’est-ce qu’une Toolbox ?

Une Toolbox est un bundle d’outils nommé et réutilisable, défini une fois dans Foundry et exposé via un unique endpoint compatible MCP. N’importe quel runtime d’agent qui parle MCP peut le consommer — pas d’enfermement dans Foundry Agents.

La promesse est simple : build once, consume anywhere. Définir les outils, configurer l’authentification de façon centralisée (OAuth passthrough, identité managée Entra), publier l’endpoint. Chaque agent qui a besoin de ces outils se connecte à l’endpoint et les obtient tous.

Les quatre piliers (deux disponibles aujourd’hui)

Pilier	Statut	Ce qu’il fait
Discover	Bientôt	Trouver des outils approuvés sans recherche manuelle
Build	Disponible	Regrouper des outils en un bundle réutilisable
Consume	Disponible	Un endpoint MCP unique expose tous les outils
Govern	Bientôt	Auth centralisée + observabilité pour tous les appels

Exemple pratique

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Chercher dans la documentation et répondre aux issues GitHub.",
 tools=[
 {"type": "web_search", "description": "Recherche dans la documentation publique"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Une fois publié, Foundry fournit un endpoint unifié. Une connexion, tous les outils.

Pas d’enfermement dans Foundry Agents

Les Toolboxes sont créées et gérées dans Foundry, mais la surface de consommation est le protocole MCP ouvert. On peut les utiliser depuis des agents personnalisés (Microsoft Agent Framework, LangGraph), GitHub Copilot et autres IDEs compatibles MCP, et tout runtime parlant MCP.

Pourquoi c’est important maintenant

La vague multi-agents arrive en production. Chaque nouvel agent est une nouvelle surface pour de la configuration dupliquée, des credentials obsolètes et des comportements incohérents. La base Build + Consume suffit pour commencer à centraliser. Quand le pilier Govern arrivera, on aura une couche d’outils entièrement observable et contrôlée centralement pour toute la flotte d’agents.

Conclusion

C’est encore tôt — preview publique, SDK Python en premier, Discover et Govern à venir. Mais le modèle est solide et le design natif MCP signifie qu’il fonctionne avec les outils qu’on construit déjà. Tous les détails dans l’annonce officielle.

Où héberger vos agents IA sur Azure ? Un guide de décision pratique

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

Si vous construisez des agents IA avec .NET en ce moment, vous avez probablement remarqué quelque chose : il y a beaucoup de façons de les héberger sur Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — et tous semblent raisonnables jusqu’à ce que vous ayez réellement besoin d’en choisir un. Microsoft vient de publier un guide complet sur l’hébergement d’agents IA sur Azure qui clarifie tout ça, et je veux le décomposer du point de vue pratique d’un développeur .NET.

Les six options en un coup d’œil

Voici comment je résumerais le paysage :

Option	Idéal pour	Vous gérez
Container Apps	Contrôle total des conteneurs sans complexité K8s	Observabilité, état, cycle de vie
AKS	Conformité entreprise, multi-cluster, réseau personnalisé	Tout (c’est le but)
Azure Functions	Tâches d’agents événementielles et courtes	Presque rien — vrai serverless
App Service	Agents HTTP simples, trafic prévisible	Déploiement, config de scaling
Foundry Agents	Agents sans code via portail/SDK	Presque rien
Foundry Hosted Agents	Agents framework personnalisé avec infra gérée	Uniquement votre code d’agent

Les quatre premières sont du compute généraliste — vous pouvez y exécuter des agents, mais elles n’ont pas été conçues pour ça. Les deux dernières sont natives aux agents : elles comprennent les conversations, les appels d’outils et les cycles de vie des agents comme des concepts de première classe.

Foundry Hosted Agents — le sweet spot pour les développeurs .NET d’agents

C’est ce qui a attiré mon attention. Les Foundry Hosted Agents se situent pile au milieu : vous obtenez la flexibilité d’exécuter votre propre code (Semantic Kernel, Agent Framework, LangGraph — peu importe) mais la plateforme gère l’infrastructure, l’observabilité et la gestion des conversations.

La pièce clé est le Hosting Adapter — une fine couche d’abstraction qui connecte votre framework d’agents à la plateforme Foundry. Pour Microsoft Agent Framework, ça ressemble à ça :

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

C’est toute votre histoire d’hébergement. L’adapter gère la traduction de protocoles, le streaming via server-sent events, l’historique de conversation et le traçage OpenTelemetry — tout automatiquement. Pas de middleware personnalisé, pas de plomberie manuelle.

Le déploiement est vraiment simple

J’ai déployé des agents sur Container Apps avant et ça fonctionne, mais on finit par écrire beaucoup de code de colle pour la gestion d’état et l’observabilité. Avec Hosted Agents et azd, le déploiement c’est :

# Installer l'extension agent IA
azd ext install azure.ai.agents

# Initialiser depuis un template
azd ai agent init

# Construire, pousser, déployer — terminé
azd up

Ce seul azd up construit votre conteneur, le pousse vers ACR, provisionne le projet Foundry, déploie les endpoints de modèle et démarre votre agent. Cinq étapes condensées en une seule commande.

Gestion de conversations intégrée

C’est la partie qui fait gagner le plus de temps en production. Au lieu de construire votre propre store d’état de conversation, les Hosted Agents le gèrent nativement :

# Créer une conversation persistante
conversation = openai_client.conversations.create()

# Premier tour
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Deuxième tour — le contexte est préservé
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Pas de Redis. Pas de store de sessions Cosmos DB. Pas de middleware personnalisé pour la sérialisation des messages. La plateforme gère tout simplement.

Mon framework de décision

Après avoir passé en revue les six options, voici mon modèle mental rapide :

Vous avez besoin de zéro infrastructure ? → Foundry Agents (portail/SDK, pas de conteneurs)
Vous avez du code d’agent personnalisé mais voulez un hébergement géré ? → Foundry Hosted Agents
Vous avez besoin de tâches d’agents événementielles et courtes ? → Azure Functions
Vous avez besoin d’un contrôle maximum des conteneurs sans K8s ? → Container Apps
Vous avez besoin de conformité stricte et multi-cluster ? → AKS
Vous avez un agent HTTP simple avec un trafic prévisible ? → App Service

Pour la plupart des développeurs .NET qui construisent avec Semantic Kernel ou Microsoft Agent Framework, Hosted Agents est probablement le bon point de départ. Vous obtenez le scale-to-zero, OpenTelemetry intégré, la gestion des conversations et la flexibilité de framework — sans gérer Kubernetes ni monter votre propre stack d’observabilité.

Pour conclure

Le paysage de l’hébergement d’agents sur Azure mûrit rapidement. Si vous démarrez un nouveau projet d’agent IA aujourd’hui, je considérerais sérieusement Foundry Hosted Agents avant de recourir à Container Apps ou AKS par habitude. L’infrastructure gérée fait gagner un temps réel, et le pattern hosting adapter vous permet de garder votre choix de framework.

Consultez le guide complet de Microsoft et le repo Foundry Samples pour des exemples fonctionnels.

Microsoft-Foundry | The .NET Blog