Plugin, Power Automate ou business rule ? Choisir le bon outil dans Dynamics 365

« Quand le statut passe à Validé, mettre à jour le compte parent. » Ce besoin d’une ligne peut s’implémenter en business rule, en plugin C#, en flux Power Automate ou en JavaScript sur le formulaire. Les quatre fonctionnent en démo. Un seul tient en production.

Voici comment je tranche.

La question qui décide de tout : est-ce transactionnel ?

Si la règle doit être vraie en permanence — un montant qui doit toujours correspondre, un statut qui ne peut jamais être incohérent — elle doit s’exécuter dans la transaction de la base. Cela ne laisse qu’une option : un plugin synchrone.

Tout le reste — Power Automate, JavaScript, workflows asynchrones — s’exécute après que l’enregistrement est sauvegardé. Il existe une fenêtre, de quelques millisecondes à plusieurs minutes, pendant laquelle la donnée est incohérente. Si cette fenêtre est acceptable, vous avez le choix. Sinon, non.

C’est la première question à poser, et elle élimine généralement 80 % des options.

L’arbre de décision

La règle porte sur l’affichage du formulaire ? → Business rule. Afficher/masquer, rendre obligatoire, verrouiller un champ. Pas de code, visible par les fonctionnels, et ça survit aux mises à jour. N’écrivez pas de JavaScript pour ça.

La règle doit être garantie, même via l’API ? → Plugin. Un import de données, une intégration ou un utilisateur de Power Apps ne passent pas par votre formulaire. Toute logique posée en JavaScript est contournable par construction — ce n’est pas de la validation, c’est du confort d’interface.

La règle appelle un système externe ? → Power Automate. Les connecteurs vous évitent d’écrire, de sécuriser et de maintenir un client HTTP dans un plugin. Et un plugin synchrone qui appelle un service tiers est une mauvaise idée : vous mettez la latence d’un réseau externe dans votre transaction.

La règle est un traitement de masse ou planifié ? → Power Automate planifié, ou une console app selon le volume. Au-delà de quelques milliers d’enregistrements, la limite de 2 minutes du sandbox plugin devient votre ennemie.

Ce que Power Automate coûte vraiment

Power Automate est souvent présenté comme l’option « sans code, donc moins chère ». En maintenance, c’est rarement vrai.

Ce qu’un flux vous coûte que le code ne coûte pas :

• La revue de code. Un diff Git sur un plugin se relit en deux minutes. Un diff sur la définition JSON d’un flux est illisible.
• Le débogage à froid. Six mois plus tard, comprendre pourquoi un flux à 40 actions ne se déclenche plus prend plus de temps qu’un breakpoint dans Visual Studio.
• Les limites de service. Elles évoluent, elles sont par environnement, et elles surviennent en production sous charge — pas en test.

Power Automate excelle quand la logique est simple et l’intégration complexe : trois actions et un connecteur SharePoint. Il se dégrade quand la logique est complexe et l’intégration simple : vingt conditions imbriquées sur des données Dataverse. Dans ce deuxième cas, écrivez un plugin.

Les plugins : trois règles

Quand un plugin est le bon choix, trois erreurs reviennent systématiquement.

Enregistrez-le sur la bonne étape. PreValidation pour bloquer avant tout, PreOperation pour modifier la cible sans second appel, PostOperation pour ce qui a besoin de l’enregistrement créé. Un PostOperation qui fait un Update sur sa propre cible est un aller-retour inutile — et une boucle infinie potentielle.

Filtrez les attributs. Un plugin sur Update sans filtre d’attributs s’exécute à chaque modification de n’importe quel champ. Sur une entité active, c’est des milliers d’exécutions inutiles par jour.

Ne mettez jamais d’appel réseau dans un plugin synchrone. Le sandbox coupe à 2 minutes, et vous tenez la transaction pendant tout ce temps. Si un système externe est lent ou indisponible, vos utilisateurs ne peuvent plus sauvegarder. Passez en asynchrone, ou déportez vers Power Automate.

Le tableau récapitulatif

Besoin	Outil	Pourquoi
Afficher / masquer / rendre obligatoire	Business rule	Sans code, sans maintenance
Validation garantie	Plugin PreValidation	Non contournable
Calcul sur l’enregistrement courant	Plugin PreOperation	Pas de second appel
Appel d’un système externe	Power Automate	Connecteurs, retry inclus
Traitement de masse	Flux planifié / console app	Pas de limite sandbox
Confort d’interface	JavaScript	Mais jamais comme validation

Le vrai critère

Au moment de choisir, posez-vous une question simple : qui va maintenir ça dans trois ans, et avec quels outils ?

Si la réponse est « un fonctionnel, sans Visual Studio », alors une business rule légèrement imparfaite vaut mieux qu’un plugin élégant que personne ne peut modifier. Si la réponse est « l’équipe de développement, avec Git et une CI », alors le plugin gagne.

L’outil le plus adapté est rarement le plus puissant. C’est celui qui correspond à l’équipe qui vivra avec.