Microsoft Dynamics 365 · Programmation
Microsoft Dynamics 365 est une plateforme, pas un produit. Qui cherche « programmation Microsoft Dynamics 365 » vise généralement l'un de cinq modèles de programmation très différents — plug-ins Dataverse en C#, JavaScript Client API dans le navigateur, Power Fx dans le maker low-code, AL pour Business Central ou PCF Controls en TypeScript. Nous situons ces cinq mondes, montrons quand la programmation est la bonne réponse à la place de la configuration, et exposons nos packages, TJM et six erreurs typiques de programmation. Avec 20+ ans de pratique Microsoft depuis CRM 3.0.
Clarté des termes
Trois termes sont mélangés sur le marché — customization, configuration et custom development. Qui compare des offres devrait les distinguer proprement.
Configuration désigne ce que vous obtenez sans éditeur de code — adapter les tables, concevoir les forms, définir des Business Rules, monter des workflows, attribuer des Security Roles, configurer des views. Qui travaille dans le monde moderne Power Apps Maker voit la configuration comme « cliquable » au premier abord. Elle produit des artefacts solution transportés par l'ALM Dev/Test/Prod — mais pas de build, pas de compile.
Customization est le terme générique Microsoft pour toutes les parts non-standard d'une solution Dynamics 365. Au sens strict, il désigne la part code — plug-ins, JavaScript, PCF Controls, Custom APIs, extensions AL. Au sens large, il couvre aussi les adaptations structurelles (Custom Entities, Custom Fields, Custom Workflows). Nous utilisons « customization » au sens large Microsoft et disons « composants pro-code » quand nous visons concrètement la part code.
Custom Development désigne les composants logiciels plus larges, souvent autonomes — un portail Power Apps avec custom branding, une couche backend Azure Functions pour l'intégration de systèmes tiers, une mobile app native ou un front-end web propre contre la Web API Dataverse. Le custom development est le pont entre la programmation plateforme et le développement logiciel libre — le domaine où notre équipe Independent Engineering travaille avec .NET, React et Node.
Une seconde ligne de partage passe entre les mondes de modules : Customer Engagement (Sales, Customer Service, Field Service, Project Operations, Customer Insights) s'étend via plug-ins en C#, JavaScript Client API, PCF Controls, Power Fx et Custom APIs — ce monde tourne sur Dataverse. Business Central en tant qu'app ERP PME s'étend via extensions AL, un langage propre avec runtime et compilateur dédiés. Finance & Operations utilise X++ et Extensions dans l'Application Object Tree et constitue un troisième monde, pour lequel nous collaborons avec des partenaires F&O spécialisés.
Modèles de programmation
Quand vous cherchez « programmation Dynamics 365 » ou « programmation Dynamics CRM », vous visez l'un de ces cinq modèles. Ils diffèrent par le langage, la runtime, le lieu d'exécution et le profil de skill — et sont en général utilisés en combinaison.
.NET · C# · server-side
Composants .NET server-side en C# qui réagissent aux événements Pre/Post-Operation dans le pipeline Dataverse — par exemple « après la sauvegarde d'un Account, recalculer la limite de crédit ». Utilisés dans tous les modules CE (Sales, Customer Service, Field Service, Project Operations).
Profil de skill : profondeur .NET, Dataverse SDK, IPluginExecutionContext, limites de la sandbox plug-in (2 minutes d'exécution, 5 Mo outgoing).
JavaScript · TypeScript · browser-side
Logique browser-side dans le formulaire Web Unified Interface — afficher/masquer des champs, validations avec dialogue, refresh de sub-grids après appels API. Les Web Resources sont déployées et versionnées via ALM en solutions.
Profil de skill : JavaScript ES6+, idéalement TypeScript, Xrm.WebApi, cycle de vie du Form Context, patterns Async/Await.
Low-code · déclaratif
Langage de formule déclaratif (syntaxe proche d'Excel) pour les Canvas Apps dans Power Apps et les Cloud Flows dans Power Automate. Power Fx est simultanément low-code dans le portail Maker et pro-code en source control YAML.
Profil de skill : Power Apps Canvas, connecteur Dataverse, patterns de performance pour grandes listes, ALM avec Managed Solutions.
AL · proche Pascal · ERP
Langage des extensions Business Central, héritier du monde C/AL de Navision. Le code AL s'exécute en extension versionnée sur le serveur Business Central (cloud ou on-premises), avec symbol-files, traductions et app-manifest.
Profil de skill : patterns AL, architecture serveur Business Central, AL Code Analyzers, workflows de traduction, processus de soumission AppSource pour les ISV.
TypeScript · React · UI
PowerApps Component Framework — custom controls TypeScript utilisés comme champs ou datasets remplacés dans les Model-Driven Apps et Canvas Apps. Par exemple un Gantt-Chart interactif à la place d'une sub-grid ou un color-picker propre.
Profil de skill : TypeScript, React (optionnel mais fréquent), pac-cli, toolchain de build npm, ManifestSchema, cycle de vie ControlContext.
Azure · .NET · Custom APIs
Au sens strict, pas un modèle de programmation « Dynamics 365 » — mais en pratique difficilement séparable. La logique complexe migre vers Azure Functions ou Dataverse Custom APIs, parce que les limites plug-in (2 min, 5 Mo) sautent sinon. Appel via Web API, REST ou Service Bus.
Profil de skill : .NET, hosting Azure Functions, Service Bus, Application Insights, Managed Identity, OAuth contre Dataverse.
Heuristique de décision
Avant chaque customization, la question : peut-on s'en passer ? Une heuristique grossière que nous utilisons dans le Discovery Spike pour séparer les parts.
| Exigence | Configuration (no-code) | Programmation (low- ou pro-code) |
|---|---|---|
| Logique de formulaire (afficher/masquer un champ) | Business Rules | JavaScript Client API (si plusieurs conditions ou lookups asynchrones) |
| Automatisation de workflow | Power Automate Cloud Flows | Plug-ins Dataverse (si synchrone ou transactionnel) |
| Connecter une API externe | Connecteur Power Automate (connecteurs standard) | Azure Functions ou Custom Connector (si auth-spécifique ou haute fréquence) |
| Validation complexe | Business Rules pour règles simples | Plug-in ou JavaScript Client API (si cross-entity ou contrôle agrégé) |
| Composant UI propre | Form Designer avec contrôles standard | PCF Control (si élément interactif comme Gantt, calendrier, carte) |
| Logique de calcul | Calculated & Rollup Columns | Plug-in (si limites Rollup ou vitesse critique) |
Règle empirique : si vous couvrez 80 % de l'exigence dans le standard, on reste en configuration. Dès que plus de 20 % transparaît comme « chez nous c'est différent », les composants pro-code entrent en jeu. Dans le Discovery Spike, nous séparons les parts proprement — et évitons que la customization naisse de l'habitude plutôt que de la nécessité.
Critères de sélection · neutres
Ces critères valent que vous travailliez avec arades ou avec un autre Microsoft Partner. Qui se présente comme « développeur Dynamics 365 » devrait pouvoir répondre aux six critères — sinon, un profil de skill déséquilibré apparaît, avec coûts induits.
01
Combien de plug-ins en production ? Combien de Custom APIs ? Quelle profondeur de compréhension de la sécurité Dataverse, des Business Units, de la Hierarchical Security, de la Field-Level Security ? Qui esquive ces questions a rarement construit sous charge.
02
Source control avec Azure DevOps ou GitHub, Managed Solutions en Test et Prod, environnements Dev/Test/Prod, Power Platform Build Tools pour CI/CD. Qui travaille sans pipeline ALM bâtit des solutions que personne ne peut faire évoluer hors du développeur d'origine.
03
Si Business Central est dans le jeu ou s'y annonce : véritable expérience extension AL, pas seulement l'héritage C/AL de Navision. Symbol-files, workflows de traduction, processus de soumission AppSource pour ISV, architecture serveur Business Central cloud et on-premises.
04
Qui code de la logique de form en patterns 2019 (var au lieu de let, pas de Promise.all, notation Xrm.Page ancienne) laisse de la dette technique. ES6+, idéalement TypeScript, Async/Await propre dans le cycle de vie du Form Context — c'est le standard minimal d'aujourd'hui.
05
Azure Functions, Service Bus, Application Insights, Managed Identity, OAuth contre Dataverse — ces skills sont nécessaires dès que les limites plug-in sautent ou que des systèmes externes entrent en jeu. Le custom code Dataverse seul suffit rarement pour un setup PME/ETI en production.
06
TJM ou sprint au forfait — les deux modèles sont légitimes, mais ils doivent être annoncés ouvertement. Qui répond « ça dépend » à la question « combien ça coûte ? » sans s'engager sur une fourchette n'a pas de modèle de pricing ou redoute la réponse.
Où arades est forte
Nous ne faisons pas tout aussi bien. Ces six domaines sont ceux où nous travaillons à partir d'une pratique profonde — avec nos propres bases de code, des patterns documentés et des implémentations PME/ETI productives dans le dos.
Composants .NET server-side pour les modules CE. Profondeur dans les pipelines Pre- et Post-Operation, plug-in steps avec Filtering Attributes, séparation propre entre synchrone et asynchrone. Avec un historique CRM on-premises remontant à CRM 3.0, expérience de migration vers le cloud.
Visuels custom TypeScript — composants Gantt, composants carte, renderers de sub-grid propres. Plus les Web Resources classiques pour la logique de form. Nous séparons proprement où une Web Resource suffit et où un PCF Control justifie la valeur ajoutée.
Power Fx en Canvas Apps avec patterns de performance clairs, Custom Connectors pour APIs REST propres, ALM basé solution avec pipeline Dev/Test/Prod. Nous mettons le low-code là où il porte — et bâtissons une colonne pro-code là où il ne porte pas.
Extensions pour Business Central Cloud et on-premises. Structures d'app-manifest propres, workflows de traduction, AL Code Analyzer en CI. Pour les projets ISV, nous connaissons le processus de soumission AppSource par pratique propre.
Quand la programmation plateforme atteint ses limites, nous avons un stack propre dans le dos : .NET, Azure (App Service, Functions, Service Bus), frontends React, backends Node. Ainsi nous bâtissons des Custom APIs, des services backend et des UI spéciales comme extension propre du monde Dynamics 365.
Quality gates, stratégie de test documentée, revues de code en double regard, definition-of-done définie par sprint. Livraison de custom code comme process — pas comme « le développeur sait ce qu'il fait ».
Packages & TJM
Du Discovery Spike d'une semaine au retainer Embedded Developer pluri-mensuel. Quelle forme convient dépend de la clarté de l'exigence et de la vitesse souhaitée — pas du volume seul.
1 semaine au forfait. Analyse des exigences, esquisse d'architecture, prototype cliquable dans l'environnement cible, cadre d'effort documenté pour le sprint suivant. Idéal quand l'exigence est encore floue — le spike l'affine.
4 semaines au forfait. Livraison concrète de customization — par exemple trois plug-ins, un PCF Control, une couche JavaScript pour un formulaire, une intégration Power Automate. Avec revue de code, stratégie de test et pipeline ALM.
Retainer mensuel. Un à quatre développeurs pour trois à douze mois, intégrés à votre équipe ou comme squad externe. Adapté aux roadmaps à besoin de livraison continu — par exemple lors du build d'une solution sectorielle propre sur Dataverse.
TJM concrets après le Discovery de 30 minutes — selon la séniorité (junior, senior, architecte) et le profil de skill (plug-in, PCF, AL).
Six erreurs de programmation typiques
Ces six erreurs apparaissent dans presque tout parc de custom code que nous prenons en revue d'architecture ou phase Knowledge Recovery — dans le code de partenaires tiers, et parfois aussi chez nous d'années plus anciennes. Les nommer plutôt que les taire.
Accès SQL direct à la base Dataverse, patches DLL non autorisés dans la sandbox plug-in, appels API « non documentés mais fonctionnels » contre des endpoints internes Microsoft. Ça marche — jusqu'à la prochaine Release Wave. Microsoft ne tolère pas ce terrain et le lift-and-shift vers le cloud échoue de manière fiable dessus.
Un plug-in en Pre-Operation appelle une API externe qui répond en 30 secondes (ou pas). Cela bloque la transaction de sauvegarde de l'utilisateur, fait sauter la limite des 2 minutes et conduit à des erreurs de timeout à chaque troisième opération. Correct : asynchrone ou via Service Bus Queue avec Azure Function.
Dans le plug-in : « lookupOptionSetValue = 100000001 » — le GUID ou la valeur OptionSet d'un lookup directement dans le code. Ça marche en Dev, casse en Test (autre GUID), casse en Prod (encore un autre GUID). Correct : entité de configuration avec lookup par nom de schéma ou FetchXML contre une colonne d'unicité.
Un fichier JavaScript est patché plusieurs fois sans mise à jour de solution, le cache navigateur livre l'ancienne version, l'utilisateur voit un mélange aléatoire. Correct : import de solution versionné, suffixe de cache-busting à chaque modification, idéalement avec pipeline de build.
Une Canvas App qui tourne vite en démo avec 50 enregistrements met 18 secondes pour le premier render en production avec 12 000. Power Fx a des limites de délégation claires — qui les ignore bâtit des apps qui fonctionnent en démo et gèlent en prod. Correct : prendre au sérieux les delegation warnings, logique d'agrégation dans Dataverse plutôt qu'au client.
La customization est faite directement en production, « parce que c'est plus rapide ». Les solutions sont unmanaged, personne ne sait ce qui est vraiment productif. En cas de rollback, la solution disparaît. Correct : environnements Dev/Test/Prod, Managed Solutions à partir de Test, source control pour tous les composants custom code.
Qualification
Nous programmons Dynamics 365 depuis Microsoft CRM 3.0 (2005). À travers tous les changements de plateforme, toutes les renommages de Release Wave, toutes les adaptations de modèle de licences — et avec notre propre base de code dans le dos. Nos développeurs éprouvés travaillent en équipes de deux à quatre personnes avec un profil de skill mixte, pas en franc-tireurs fullstack.
Questions fréquentes
Nous démarrons par un Discovery Spike au forfait (1 semaine, à partir de 6 500 € net). Il en résulte un prototype cliquable et un cadre d'effort réaliste. Un sprint de customization sur quatre semaines est au forfait à partir de 25 000 € net. Pour les projets plus longs, nous fonctionnons en retainer Embedded Developer avec tarif journalier ou mensuel transparent. Le TJM concret dépend du niveau de séniorité et du profil de skill, et se communique après le Discovery.
AL (Application Language) est le langage pour Business Central — l'app ERP PME de Dynamics 365. Le code AL s'exécute en extensions sur le serveur Business Central et hérite du monde C/AL issu de Navision. Les plug-ins désignent généralement les plug-ins Dataverse : composants .NET server-side en C# qui réagissent aux événements Pre/Post dans les apps CE (Sales, Customer Service, Field Service, Project Operations). Les deux sont du pro-code, livrés avec source control et pipeline ALM — mais ils tournent sur deux runtimes différentes.
Customer Engagement (Sales, Customer Service, Field Service, Project Operations) tourne sur Dataverse et s'étend via plug-ins (.NET), JavaScript Client API, Power Fx, PCF Controls et Custom APIs. Finance & Operations utilise X++, Extensions et le Visual Studio Application Object Tree — un univers où vous adaptez plutôt les modules SCM et Finance. arades sert le stack CE et Business Central elle-même ; pour le custom code F&O, nous travaillons avec des partenaires F&O spécialisés de notre réseau. Contexte dans le domaine thématique D365 ERP.
En partie oui, en partie non. Les plug-ins écrits dans les règles de support (pas d'accès SQL direct, pas d'impersonation hors pipeline plug-in) peuvent souvent être migrés vers Dataverse avec un effort maîtrisé. Le JavaScript des Web Forms et Web Resources doit être adapté à l'Unified Interface. Les rapports SSRS classiques sont en général remplacés par Power BI. Nous examinons le parc custom code dans un Discovery Spike et livrons un plan de migration avec quote de re-build, quote de lift-and-shift et quote de non-migration assumée.
Pour les Canvas Apps et flux Power Automate : oui, avec des garde-fous clairs. Nous utilisons Power Fx dans des apps PME/ETI en production, mais en respectant quatre points — architecture de source de données propre (de préférence Dataverse), tests de performance explicites sur les listes de plus de 2 000 enregistrements, pipeline ALM avec solutions Dev/Test/Prod, et séparation claire entre Citizen Development et composants pro-code. Là où Power Fx atteint des limites de performance ou de complexité, nous construisons des Custom APIs sur Azure Functions en backend.
La configuration désigne ce que vous obtenez dans le portail Maker sans code : adapter les forms, définir des views, créer des Business Rules, monter des workflows simples, attribuer des Security Roles. La customization désigne le code : plug-ins, JavaScript Client API, PCF Controls, Custom APIs, extensions AL. Règle empirique — si votre exigence se couvre à 80 % ou plus dans le standard, on reste en configuration. Dès que plus de 20 % transparaît comme « chez nous c'est différent », les composants pro-code entrent en jeu.
Si votre processus est standard, le standard suffit. Microsoft Dynamics 365 couvre beaucoup, et beaucoup de ce qui était custom code il y a dix ans est aujourd'hui configuration ou Power Fx. Le développement externe est rentable quand votre processus est un avantage concurrentiel (logique sectorielle, modèles de calcul propres, systèmes tiers intégrés) ou quand vous devez atterrir dans le cloud avec d'anciennes parts custom. Dans le Discovery Spike, nous séparons ce qui devient configuration et ce que nous codons réellement.
Azure DevOps Repos ou GitHub pour le source control, Power Platform Build Tools pour le déploiement des solutions, Azure Pipelines pour CI/CD. Environnements Dev/Test/Prod avec Managed Solutions en Test et Prod, Unmanaged en Dev. Pour Business Central, nous utilisons les templates AL officiels et la toolchain Microsoft AL Language Extension. Les PCF Controls sont empaquetés via build npm avec pac-cli. L'ALM n'est pas un add-on chez nous, mais une base de livraison.
Rarement. Le développement de plug-ins en C# exige une profondeur .NET et la compréhension de l'API Dataverse. La JavaScript Client API exige une expérience front-end sur le cycle de vie de l'Unified Interface. AL pour Business Central est un univers à part, avec ses patterns propres. Les PCF Controls sont du TypeScript avec parts React. Power Fx est déclaratif. Nous travaillons en petites équipes mixtes (typiquement 2 à 4 personnes) qui se partagent les modèles — l'idée du « développeur Dynamics fullstack qui sait tout faire » est un conte marketing.
Quand ce que vous codez serait en fait un standard Microsoft que vous ne connaissez pas. Quand le code fait des opérations base de données synchrones dans un plug-in qui attend une API externe. Quand du JavaScript porte une logique de formulaire qu'une Business Rule pourrait modéliser. Quand des GUIDs sont codés en dur au lieu d'être obtenus via FetchXML. Quand personne sauf le développeur d'origine ne comprend le code. Avant chaque customization, la question chez nous est : peut-on s'en passer ?
Pour aller plus loin
La page service correspondante au format de livraison : Discovery Spike, sprint de customization et Application Care. Avec modèles de livraison, logique Discovery et transition vers l'Application Care.
Avant de faire programmer : choix de modules, architecture des licences et roadmap. Discovery, atelier stratégique et revue d'architecture.
Quatre catégories d'extensions : marketplace AppSource, custom solutions, solutions propres, plug-ins. Avant le développement custom, un coup d'œil à ce qui existe déjà.
Trois packages d'implémentation et le modèle en 4 phases (Discovery, Build, Migration et UAT, Hypercare). La programmation est généralement une partie de la phase Build.
Après le go-live : contrat Application Care prévisible au forfait mensuel pour la maintenance du custom code, releases et extensions.
Quand la programmation plateforme atteint ses limites : stack propre avec .NET, Azure, React et Node — comme extension propre du monde Dynamics 365.
30 min · gratuit · sans engagement
Racontez-nous ce qui doit être programmé — une extension plug-in, un PCF Control, une extension AL ou une app Power Fx. Nous classons, proposons le modèle de programmation adapté et donnons une première fourchette d'effort. En cas d'adéquation, passage vers un Discovery Spike.
