Veille Microsoft7 min de lecture

Serveur MCP Dynamics 365 ERP : l'essentiel pour devs et DSI F&O

Le serveur MCP D365 ERP ouvre aux agents IA les données, formulaires et classes X++ de F&O, filtrés par rôle de sécurité. Prérequis, outils, limites.

La réponse courte

Le serveur Dynamics 365 ERP MCP est le point d'entrée Microsoft qui permet à un agent IA (construit dans Copilot Studio ou dans un autre client compatible MCP) d'agir dans Finance & Operations : lire et écrire des données, utiliser les formulaires comme un utilisateur, et appeler des classes X++ exposées comme outils. Tout ce que l'agent voit et fait est filtré par le rôle de sécurité de son identité.

Pour un développeur X++, le point clé est la troisième famille d'outils : quand la logique métier n'est accessible ni par une data entity ni par un formulaire, c'est à vous d'écrire la classe X++ que l'agent appellera. Pour un DSI, le point clé est la sécurité : un agent a exactement les droits du rôle que vous lui attribuez, ni plus ni moins.

Quelles sont les trois familles d'outils ?

La documentation Microsoft Learn décrit trois catégories d'outils dynamiques :

  • Outils de données (data_find_entity_type, data_get_entity_metadata, data_find_entities, data_create_entities, data_update_entities, data_delete_entities) : opérations CRUD via les data entities et OData. Les insertions imbriquées (deep insert) ne sont pas prises en charge. En version 10.0.48, data_find_entities_sql remplace la lecture OData. Microsoft recommande de privilégier ces outils pour le CRUD : moins d'appels, meilleures performances.
  • Outils de formulaire (form_open_menu_item, form_set_control_values, form_click_control, form_save_form, filtres et tris de grille, etc.) : l'agent navigue dans les formulaires via les API serveur, sans ouvrir de session client, et déclenche les actions disponibles derrière les boutons.
  • Outils d'action (api_find_actions, api_invoke_action) : l'agent trouve et invoque des classes X++ conçues comme outils d'IA, qui implémentent l'interface ICustomAPI et dont l'élément de menu action est couvert par un privilège.

Le contexte est dynamique : à chaque appel, le serveur renvoie le « view model » de l'application en tenant compte de vos extensions, de la configuration et des personnalisations. Vos champs et formulaires personnalisés sont donc visibles par l'agent sans développement supplémentaire, dès lors que son rôle y donne accès.

Quels prérequis pour l'activer ?

  • Version F&O minimale : 10.0.47, ou 10.0.46 PQU-2, ou 10.0.45 PQU-7.
  • Fonctionnalité « Dynamics 365 ERP Model Context Protocol server » activée dans la gestion des fonctionnalités (activée par défaut).
  • Plateforme d'agent déclarée dans la page « Allowed MCP Clients ».
  • Environnement de niveau 2 (Tier 2) ou supérieur, ou environnement de développement unifié (UDE). Les environnements hébergés dans le cloud (CHE) ne sont pas pris en charge.

Attention à l'ancienne version : le serveur « statique » à 13 outils, bâti sur le connecteur Dataverse, est retiré le 1er octobre 2026. Si un agent l'utilise encore, il faut le basculer sur le serveur dynamique.

Comment la sécurité fonctionne-t-elle ?

Le rôle de sécurité de l'utilisateur authentifié pour l'agent détermine tout : les éléments de menu renvoyés, les entités listées, les API proposées, les champs et actions visibles dans un formulaire. Un appel explicite vers un objet non autorisé est rejeté. Microsoft cite l'exemple d'un agent affecté au rôle « Purchasing Agent » : il n'accède qu'aux objets des devoirs et privilèges de ce rôle.

Conséquence pratique : concevez un rôle dédié par agent, limité à son périmètre. C'est à la fois une mesure de sécurité et un gain de qualité, car moins l'agent a d'objets à parcourir, mieux il choisit le bon formulaire ou la bonne entité. Certains formulaires d'administration (gestion des fonctionnalités, utilisateurs, configuration de la sécurité) sont de toute façon exclus.

Côté licences, l'identité d'un agent affectée au rôle « System agent » est exemptée de licence utilisateur F&O ; ce rôle ne donne aucun droit, il faut lui ajouter les rôles métier nécessaires. Les appels d'outils sont facturés selon le client d'agent (tarif « Agent Action » dans Copilot Studio, 0,1 crédit Copilot par appel dans les autres clients, avec des exemptions pour les licences Premium). Vérifiez ces conditions sur Learn avant tout chiffrage.

Quelles limites connaître ?

  • Métadonnées et guidage renvoyés en anglais (en-us) uniquement ; dates et nombres au format ISO.
  • Certains contrôles non pris en charge (calendrier, organigramme, éditeur HTML, image, bouton radio…), ainsi que les contrôles personnalisés.
  • Onglets de formulaire fermés par défaut : l'agent doit les ouvrir.
  • Filtres de grille limités à l'opérateur « matches ».
  • Serveur indisponible pendant les fenêtres de maintenance.
  • Ajout au Copilot intégré de F&O (panneau latéral) pas encore pris en charge.

Et pour les développeurs X++ ?

Trois chantiers concrets. D'abord, la qualité de vos data entities : ce sont elles que l'agent utilise en priorité pour lire et écrire. Une entité custom bien nommée et documentée est directement exploitable. Ensuite, les classes d'action : une opération composite, un calcul ou une validation qui n'existe pas derrière un bouton doit être écrite en X++ et exposée comme outil d'IA. Nous détaillons ce cas dans agents Copilot Studio pour D365 F&O : ce qui demande encore du X++. Enfin, la sécurité : privilèges, devoirs et rôles dédiés aux agents.

À ne pas confondre avec l'usage de MCP chez Skalp AI. Le serveur Microsoft sert à faire agir un agent dans l'ERP. L'offre Pro de Skalp utilise une connexion MCP vers votre instance et le contexte de votre Azure DevOps pour générer du code X++ aligné sur votre existant, livré avec tests unitaires et validé par votre DSI : voir MCP pour D365 F&O. Deux usages complémentaires d'un même protocole. Pour le cadre général, lisez développer en X++ sans consultant en 2026 et comparez les offres. Microsoft propose d'ailleurs un autre serveur MCP pour sa roadmap produit : voir la fin des release waves.

Sources

Questions fréquentes

Faut-il coder pour utiliser le serveur MCP Dynamics 365 ERP ?

Non pour les données et les formulaires : l'agent utilise les data entities et les formulaires existants, extensions comprises. Oui quand la logique n'est accessible ni par une entité ni par un formulaire : il faut alors écrire une classe X++ exposée comme outil d'IA.

Le serveur fonctionne-t-il sur un environnement de développement cloud (CHE) ?

Non. Il faut un environnement Tier 2 ou supérieur, ou un environnement de développement unifié (UDE).

Que devient l'ancien serveur MCP à 13 outils ?

Ce serveur « statique » est retiré le 1er octobre 2026 selon Microsoft Learn. Les agents qui l'utilisent doivent passer au serveur dynamique.

Prêt à transformer votre D365 ?

Rejoignez les DSI qui développent leurs tickets D365 en 1h pour 1 crédit (≈ 400 € en Basic, 200 € en Pro).