Le modèle d'extensions vient en premier dans les questions d'entretien d'un développeur Dynamics 365 Finance & Operations. Le code standard n'est plus modifiable. On l'étend avec des classes d'extension et la Chain of Command (CoC), des gestionnaires d'événements, des extensions de tables, de formulaires et d'énumérations. Un profil qui a passé des années sur AX 2012 connaît X++ et les tables standard, mais il doit expliquer comment il obtient le même résultat sans overlayering.
Le reste du poste se partage entre les données et les traitements. Les data entities servent aux imports du Data management framework (DMF), aux intégrations OData et aux échanges avec Dataverse. Les traitements lourds tournent en batch avec le framework SysOperation. Les états sortent en SSRS, et les formats réglementaires ou bancaires en Electronic Reporting. Demandez un exemple concret pour chacun : une entité créée, un batch qui a posé problème, un état modifié.
Sur le run, l'expérience s'entend vite. Un développeur confirmé parle de requêtes set-based, de transactions, de conflits de mise à jour et de Trace Parser. Il sait faire passer un package par Azure DevOps, une sandbox, puis la production. La certification MB-500 valide les bases et se renouvelle chaque année. Le PDF ajoute un cas de 20 minutes sur l'import des confirmations de commandes fournisseurs.
Les briques de Finance & Operations côté développeur
X++ et Visual Studio
Le langage de l'ERP, proche du C#, avec des requêtes SQL écrites directement dans le code (select, while select). On développe dans Visual Studio avec l'extension Finance and Operations, sur une machine de développement ou, avec l'expérience développeur unifiée, sur un environnement créé depuis le Power Platform admin center. Le code est rangé en modèles et en packages.
Extensions et Chain of Command
La seule façon de personnaliser le standard. Une classe d'extension enveloppe une méthode existante et doit appeler next pour garder le comportement d'origine. Les extensions de tables, de formulaires et d'énumérations ajoutent des champs, des contrôles ou des valeurs. Commencez l'évaluation par là.
Data entities et DMF
Une data entity regroupe plusieurs tables en un objet métier, un client ou une ligne de commande par exemple. Elle sert aux imports et exports du Data management framework, qui passent par une table de staging, et aux intégrations OData. Une entité mal conçue ralentit tous les imports qui l'utilisent.
Batch et SysOperation
Les traitements longs (facturation, calculs, imports récurrents) tournent en batch sur le serveur. Le framework SysOperation sépare le contrat de données, le contrôleur et le service. Les classes RunBaseBatch restent nombreuses dans le code hérité. Vérifiez que la personne sait découper un gros traitement en tâches parallèles.
SSRS et Electronic Reporting
Les documents imprimés (factures, bons de livraison) restent souvent en SSRS, avec une classe qui prépare les données dans une table temporaire. Electronic Reporting (ER) produit les fichiers réglementaires et les formats de paiement par configuration, souvent sans X++. Le développeur doit savoir choisir entre les deux.
Sécurité : rôles, devoirs, privilèges
Les droits se construisent en couches. Un privilège donne accès à un point d'entrée (menu, bouton, service), un devoir regroupe des privilèges, un rôle regroupe des devoirs. Les politiques XDS (extensible data security) filtrent les lignes, par exemple par site ou par entité juridique.
Intégrations : OData, business events, dual-write
Les systèmes externes lisent et écrivent par OData sur les entités publiques, ou appellent des services personnalisés. Les business events envoient un message vers Azure Service Bus, Event Grid ou Power Automate quand un document est validé. Le dual-write synchronise des tables avec Dataverse en quasi temps réel.
Azure DevOps, LCS et Power Platform admin center
Le code est versionné dans Azure DevOps, en Git ou en TFVC, et compilé par un pipeline qui produit un package déployable. Lifecycle Services (LCS) gère encore les environnements de nombreux projets, et Microsoft en déplace la gestion vers le Power Platform admin center. Demandez comment un package arrive en production chez le dernier client.
Le développeur Dynamics 365 Finance & Operations travaille avec des consultants fonctionnels finance, achats, ventes ou logistique, qui rédigent les spécifications. Les offres viennent d'intégrateurs Microsoft et d'équipes internes qui maintiennent l'ERP, sur des déploiements, des migrations depuis AX 2012 ou de la maintenance. Elles citent X++, Visual Studio, Azure DevOps, LCS, les data entities, SSRS, parfois Dynamics 365 Commerce ou Power Platform. La certification Finance and Operations Apps Developer Associate (examen MB-500) atteste les bases. Précisez dans l'offre les modules concernés, la part de développement neuf et de maintenance, et l'avancement d'une éventuelle migration depuis AX.
Ce qu'un développeur X++ doit maîtriser
- X++ et modèle d'extensions (CoC)
- Data entities, DMF et intégrations
- Batch et framework SysOperation
- Requêtes, transactions et performance
- Sécurité, états et Electronic Reporting
- ALM, déploiement et mises à jour
Cinq situations X++ à soumettre en entretien
Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.
Question 1 · confirmé
Le client veut ajouter un contrôle à la validation d'une commande client standard. Comment l'écrivez-vous sans toucher au code de Microsoft ?
Une bonne réponseUne classe d'extension finale, déclarée avec l'attribut ExtensionOf sur la classe ou la table concernée, qui enveloppe la méthode de validation par Chain of Command. Le code appelle next, puis ajoute son contrôle avant ou après selon le besoin. La personne vérifie que la méthode peut être enveloppée (publique ou protégée, sans attribut Wrappable(false)) et cite les gestionnaires d'événements quand un délégué existe à cet endroit.
Signal d'alerteModifier directement la méthode standard, comme sous AX 2012. Ou oublier l'appel à next, ce qui casse le comportement d'origine et celui des autres extensions.
Question 2 · confirmé
Un import DMF de 200 000 clients prend quatre heures. Où cherchez-vous ?
Une bonne réponseD'abord dans l'historique d'exécution du projet, pour savoir si le temps passe dans le chargement vers la table de staging ou dans le passage du staging vers les tables cibles. Puis dans l'entité : méthodes surchargées qui forcent un traitement ligne à ligne, validations inutiles pendant une reprise, jointures lourdes. Les pistes : le traitement set-based quand l'entité le permet, l'import en batch découpé en plusieurs tâches avec les paramètres de parallélisme de l'entité, la désactivation du suivi des modifications pendant la reprise.
Signal d'alerte« On ajoute un index » sans mesure, ou relancer l'import sans savoir à quelle étape le temps passe.
Question 3 · senior
Une facturation nocturne en batch traite 50 000 commandes et déborde sur la matinée. Comment la réécrivez-vous ?
Une bonne réponseAvec SysOperation, un contrôleur qui découpe le travail en lots et crée plusieurs tâches batch qui tournent en parallèle sur les serveurs batch disponibles. Chaque tâche a sa propre transaction et journalise ses erreurs, pour qu'une commande en échec ne bloque pas les autres. La personne parle de la reprise des commandes en erreur, de la répartition équilibrée des lots et de la charge laissée sur la base quand les utilisateurs arrivent.
Signal d'alerteUne seule tâche qui boucle sur toutes les commandes dans une transaction unique. Ou « on ajoute un serveur batch » sans revoir le code.
Question 4 · confirmé
Vous devez mettre à jour un champ sur 300 000 lignes d'une table. Comment l'écrivez-vous en X++ ?
Une bonne réponseUn update_recordset dans une transaction (ttsbegin, ttscommit), qui part en une seule requête SQL. La personne sait que l'opération repasse en ligne à ligne si la table a une méthode update surchargée, la journalisation de base de données ou des abonnés aux événements, et qu'on peut l'éviter avec skipDataMethods ou skipEvents quand la logique métier le permet. Elle pense au verrouillage pendant l'opération et découpe au besoin.
Signal d'alerteUn while select forupdate avec un update par ligne, sans voir que cela fait 300 000 allers-retours vers la base.
Question 5 · junior à confirmé
Les acheteurs doivent voir un nouveau bouton, et les autres utilisateurs non. Comment donnez-vous l'accès ?
Une bonne réponseLe bouton est relié à un menu item, déclaré comme point d'entrée d'un privilège avec le bon niveau d'accès. Le privilège entre dans un devoir, le devoir dans un rôle existant par extension ou dans un nouveau rôle. Le test se fait avec un utilisateur qui n'a que ce rôle. Les droits font partie du code et se déploient dans le package.
Signal d'alerteDonner le rôle d'administrateur système pour que le bouton apparaisse, ou créer les droits à la main en production sans les avoir dans le code.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Recrutement d'un développeur D365 F&O : questions fréquentes
Un développeur AX 2012 peut-il tenir un poste Dynamics 365 Finance & Operations ?
Le langage est le même, et sa connaissance des tables et des processus standard reste précieuse. Le modèle de personnalisation change en revanche : plus d'overlayering, des extensions et la Chain of Command, Visual Studio au lieu de MorphX, des déploiements par packages et des mises à jour imposées par Microsoft. Demandez quel projet D365 la personne a livré, et faites-lui écrire une extension CoC simple. Sans projet D365, le profil est à former.
La certification MB-500 est-elle à exiger dans l'offre ?
Elle donne la certification Finance and Operations Apps Developer Associate et se renouvelle chaque année par une évaluation en ligne, ce qui permet de voir si elle est à jour. Elle couvre l'architecture, les éléments de l'AOT, le code, les états, les données, la sécurité et la performance. Elle ne montre pas une mise en production réelle. Mettez-la en atout plutôt qu'en condition, et vérifiez l'expérience par des cas concrets.
Comment construire un test technique X++ d'une heure ?
Donnez une petite classe qui met à jour des lignes dans un while select, sans transaction, et une méthode standard à compléter. Demandez de réécrire la mise à jour en set-based, d'ajouter le contrôle par Chain of Command, puis d'exposer le résultat dans un batch SysOperation. Faites commenter à voix haute. Un environnement de développement n'est pas indispensable : une revue de code sur papier montre déjà les réflexes.
Quelle connaissance des modules finance ou logistique attendre d'un développeur ?
Assez pour lire une spécification et comprendre les tables qu'il touche : commandes, journaux, écritures, stocks, dimensions financières. Un développeur qui ne sait pas ce qu'une validation de facture produit en écritures risque de casser une chaîne qu'il ne voit pas. Demandez quels modules il a le plus pratiqués et faites-lui décrire les tables d'un flux qu'il a modifié, sans attendre le niveau d'un consultant fonctionnel.
Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.
