Sécuriser un formulaire personnalisé D365 F&O : privilège, devoir, rôle

Dans Dynamics 365 Finance & Operations, on ne donne jamais accès directement à un formulaire : on donne accès à un point d'entrée, l'élément de menu qui l'ouvre. La chaîne est la suivante : l'élément de menu est ajouté à un privilège avec un niveau d'accès (lecture, mise à jour, création, suppression…) ; le privilège est regroupé dans un devoir (une partie d'un processus métier) ; le devoir est affecté à un rôle ; le rôle est affecté aux utilisateurs.

Microsoft recommande d'affecter des devoirs aux rôles plutôt que des privilèges isolés, pour simplifier la maintenance et appliquer la séparation des tâches.

1. Créez l'élément de menu d'affichage (Display menu item) qui ouvre votre formulaire.
2. Créez les privilèges ; une convention répandue en prévoit deux : un « View » (accès Read) et un « Maintain » (accès Delete ou Update selon le besoin). Dans chacun, ajoutez l'élément de menu dans Entry Points et réglez le niveau d'accès.
3. Créez un devoir (ou étendez un devoir standard) et ajoutez-y les privilèges.
4. Ajoutez le devoir à un rôle : rôle personnalisé, ou extension d'un rôle standard.
5. Ajoutez l'élément de menu au menu du module (extension de menu).
6. Compilez, déployez, puis vérifiez avec un utilisateur non administrateur.

Le même principe s'applique aux éléments de menu action (classes, batchs) et de sortie (états). Les tables et champs accédés par le formulaire sont couverts par les permissions associées au point d'entrée.

• Pensez « tâche métier » pour les privilèges et « processus » pour les devoirs, pas « objet technique ».
• Séparez les devoirs incompatibles (créer et approuver un paiement, par exemple) : c'est la base de la séparation des tâches exigée par certaines réglementations.
• Pour limiter les lignes visibles (par société, par entrepôt…), utilisez les stratégies de sécurité des données (XDS), complémentaires du modèle par rôle.
• Après chaque mise à jour de service, revoyez vos rôles personnalisés par rapport aux rôles standard, comme le recommande Microsoft.
• Les agents IA suivent la même logique : un agent connecté à F&O agit avec les droits de son rôle. Voir serveur MCP Dynamics 365 ERP.

• Tester uniquement avec un administrateur : tout fonctionne, sauf pour les vrais utilisateurs.
• Affecter le privilège directement au rôle sans devoir.
• Oublier le niveau d'accès sur le point d'entrée (formulaire visible mais non modifiable).
• Modifier un rôle standard par over-layering au lieu d'une extension ou d'un rôle personnalisé.
• Oublier les éléments de menu secondaires ouverts depuis le formulaire (boutons, dialogues).

Privilèges, devoirs et rôles font partie du livrable d'un formulaire personnalisé, au même titre que le code. Skalp AI rédige la spécification, génère le code X++ et les tests unitaires, compile en contrôlant les bonnes pratiques, puis livre par pull request dans votre Azure DevOps : rien n'est fusionné sans la validation de votre architecte technique. Voir RSSI et extensions D365 F&O sur mesure, le cadre général dans développer en X++ sans consultant en 2026, et les offres Basic, Pro et Max (1 crédit, ≈ 400 € en Basic, 200 € en Pro, consommé seulement à la génération du code).

À lire aussi : AI landing zone pour les agents ERP.

• Microsoft Learn, « Role-based security », mise à jour du 21/01/2026, consultée le 18/10/2026.
• Microsoft Learn, « Security architecture », mise à jour du 21/01/2026, consultée le 18/10/2026.