Agents Copilot Studio pour D365 F&O : ce qui demande encore du X++

Un agent construit dans Microsoft Copilot Studio et connecté au serveur Dynamics 365 ERP MCP peut, sans développement, lire et modifier des données via les data entities et utiliser les formulaires de Finance & Operations comme un utilisateur. Le X++ reste nécessaire dans trois cas : quand la logique métier n'est accessible ni par une entité ni par un formulaire, quand il manque une data entity, et pour définir la sécurité (privilèges, devoirs, rôles) que l'agent utilisera.

Autrement dit, la question n'est pas « agent ou développement » : les agents déplacent une partie du travail vers la configuration, et concentrent le X++ sur des classes d'action plus petites, plus ciblées, mieux sécurisées.

Dans Copilot Studio, l'ajout se fait depuis l'onglet Outils : « Ajouter un outil », filtre « Model Context Protocol », sélection du serveur « Dynamics 365 ERP MCP », création de la connexion, puis « Ajouter à l'agent ». L'agent accède alors aux outils de données, de formulaire et d'action du serveur, dans la limite de son rôle de sécurité.

Microsoft Learn donne deux conseils pratiques. Le choix du modèle d'orchestration compte : la documentation recommande Claude Sonnet 4.5, ou GPT-5 (Chat) s'il n'est pas disponible, plutôt que GPT-4.1. Et les instructions de l'agent doivent dire quand utiliser quels outils, par exemple privilégier les outils de données pour le CRUD et ne passer par les formulaires qu'en dernier recours.

Pour le détail des outils, des prérequis et des limites, voir notre article sur le serveur MCP Dynamics 365 ERP.

• Logique sans interface : un calcul (solde, disponibilité, marge), une opération composite (créer un en-tête et ses lignes avec contrôles), une validation métier qui n'existe derrière aucun bouton. Learn le dit : il peut y avoir des scénarios où l'action n'est disponible ni via les entités ni via le client.
• Données non exposées : si aucune data entity ne couvre vos tables personnalisées, l'agent ne peut pas les lire efficacement. Créer l'entité est un développement X++ classique.
• Point d'entrée contrôlé : une classe d'action vous permet d'imposer vos validations et votre transaction, au lieu de laisser l'agent enchaîner des clics de formulaire.
• Sécurité : l'élément de menu action, le privilège et son rattachement à un devoir puis à un rôle font partie du livrable.

La documentation « Create AI tools with finance and operations business logic » (fonctionnalité en preview) décrit le modèle. La classe porte l'attribut AIPluginOperationAttribute, implémente l'interface ICustomAPI et est décorée avec CustomAPIAttribute (nom et description en langage naturel, utilisés par l'orchestration). Les entrées et sorties sont des data members, déclarés avec CustomAPIRequestParameter et CustomAPIResponseProperty. La logique s'écrit dans la méthode run. Extrait de Learn pour un paramètre d'entrée :

[CustomAPIRequestParameter('The customer account number', true),
    DataMember('accountNumber')]
public CustAccount parmAccountNum(CustAccount _accountNum = accountNum)
{
    accountNum = _accountNum;
    return accountNum;
}

Et pour une propriété de réponse :

[CustomAPIResponseProperty('The current customer account balance'),
    DataMember('balance')]
public AmountCur parmBalance(AmountCur _balance = balance)
{
    balance = _balance;
    return balance;
}

Ensuite : créer un élément de menu action (ObjectType = Class, Object = votre classe), l'ajouter à un privilège rattaché à un rôle, déployer, puis vider le cache d'extensions (synchronisation de base ou classe SysFlushAOD). La classe apparaît alors dans le formulaire « Synchronize Dataverse Custom APIs » et le serveur MCP la propose via api_find_actions. Sans le serveur MCP, il faut en plus créer une Custom API Dataverse et l'ajouter comme outil dans Copilot Studio.

Prérequis côté développement : un environnement de développement unifié (UDE), les solutions Copilot pour finance and operations installées et la fonctionnalité « (Preview) Custom API Generation » activée. Comme toute preview, à ne pas utiliser en production sans valider les conditions Microsoft.

• Oublier l'élément de menu action ou le privilège : la classe compile mais n'apparaît pas dans la liste des API.
• Ne pas vider le cache après déploiement : la classe existe mais ne peut pas encore être invoquée.
• Des descriptions vagues dans CustomAPIAttribute et les paramètres : l'orchestration s'en sert pour choisir l'outil et remplir les entrées.
• Un rôle d'agent trop large : plus d'objets visibles, plus de risques et une orchestration moins précise.
• Recréer en X++ ce qu'une data entity fait déjà : l'agent préfère les outils de données pour le CRUD.

Commencez par la configuration : rôle dédié, instructions précises, outils de données. Testez sur un environnement Tier 2 ou UDE. Notez chaque tâche où l'agent échoue ou passe par une longue suite de clics : ce sont vos candidats à une classe d'action ou à une data entity.

Ces développements sont courts et bien délimités, ce qui en fait de bons tickets pour Skalp AI : analyse du contexte ERP, spécification, code X++ et tests unitaires, livraison sur votre Azure DevOps et validation par votre DSI. Pour comprendre en quoi Skalp diffère de Copilot, voir Skalp AI vs Copilot pour D365 ; pour exposer vos services, interfaces et API D365 F&O ; pour le cadre général, développer en X++ sans consultant en 2026. Tarifs : offres Basic, Pro et Max, 1 crédit (≈ 400 € en Basic, 200 € en Pro, dégressif) consommé seulement à la génération du code.

• Microsoft Learn, « Build an agent with Dynamics 365 ERP MCP », mise à jour du 05/03/2026, consultée le 11/10/2026.
• Microsoft Learn, « Create AI tools with finance and operations business logic (preview) », mise à jour du 05/03/2026, consultée le 11/10/2026.
• Microsoft Learn, « Use Model Context Protocol for finance and operations apps », mise à jour du 18/08/2026, consultée le 11/10/2026.