AI landing zone : en faut-il une pour vos agents D365 F&O ?

Une AI landing zone est une architecture de référence Azure, publiée par Microsoft sur GitHub, pour déployer des applications et des agents IA de façon sécurisée et résiliente, avec des implémentations Portail, Bicep et Terraform. Elle est encore en preview.

Vous en avez besoin si vous hébergez vous-même, dans votre abonnement Azure, des agents ou des modèles qui travaillent autour de votre ERP : réseau privé, gestion des identités, passerelle vers les modèles, supervision. Vous n'en avez pas besoin si vos agents sont construits dans Copilot Studio et branchés à F&O via le serveur MCP Dynamics 365 ERP, ou si vous utilisez un service tiers qui héberge lui-même son IA : l'infrastructure est alors gérée par le fournisseur.

Selon le dépôt Azure/AI-Landing-Zones :

• C'est une « application landing zone » : elle sert de socle à des charges de travail d'applications et d'agents IA, avec ou sans « platform landing zone ».
• Elle comprend deux briques déployables ensemble ou séparément : l'Agent Landing Zone, qui s'appuie sur Microsoft Foundry, et l'AI Gateway Landing Zone, qui utilise Azure API Management comme passerelle pour gérer et servir les modèles Foundry de façon centralisée.
• Les implémentations Bicep et Terraform reposent sur les Azure Verified Modules.
• Elle suit le Cloud Adoption Framework (scénario IA) et le Well-Architected Framework (charges de travail IA), avec une check-list de conception.
• Un déploiement complet n'est pris en charge que dans certaines régions, dont, en Europe, francecentral, germanywestcentral, norwayeast, polandcentral, spaincentral, swedencentral, switzerlandnorth et uksouth.
• Elle peut utiliser des services en preview, et le projet lui-même est en preview.

• Vous construisez vos propres agents dans Microsoft Foundry, qui appellent F&O (via le serveur MCP, OData ou vos services) et manipulent des données sensibles.
• Plusieurs équipes consomment des modèles et vous voulez une passerelle unique (quotas, journalisation, contrôle des accès) : c'est le rôle de l'AI Gateway Landing Zone.
• Votre politique de sécurité impose réseau privé, résidence des données dans une région donnée et gouvernance Azure Policy pour toute charge IA.

Dans ces cas, partir d'une architecture de référence évite de réinventer le socle et facilite la revue par le RSSI.

• Vos agents vivent dans Copilot Studio et utilisent le serveur MCP Dynamics 365 ERP : l'hébergement est géré par Microsoft, la sécurité passe par les rôles F&O de l'agent. Voir serveur MCP Dynamics 365 ERP et agents Copilot Studio et X++.
• Vous utilisez un service d'IA tiers : c'est à lui de documenter son hébergement. Demandez-lui la région, l'usage de vos données et le contrôle d'accès.
• Vous en êtes au prototype : un environnement de test isolé suffit souvent avant d'industrialiser.

À titre d'exemple de ce qu'il faut demander à un fournisseur : Skalp AI indique héberger ses traitements dans Azure en Europe et ne jamais entraîner de modèle sur les données de ses clients ; le code X++ généré est livré sur votre Azure DevOps et validé par votre DSI. Voir la page RSSI et MCP pour D365 F&O.

Les termes Foundry, agent, MCP ou system of action sont définis dans notre glossaire de l'ERP agentique. Pour le cadre général du développement X++ assisté par IA : développer en X++ sans consultant en 2026. Tarifs : offres Basic, Pro et Max.

• GitHub, Azure, « AI Landing Zones » (README), consultée le 11/10/2026.
• Microsoft Learn, « What is Microsoft Foundry? », mise à jour du 13/08/2026, consultée le 11/10/2026.