Quand Power Automate est le mauvais choix : 7 critères d'exclusion

Power Automate est souvent présenté comme un outil adapté à pratiquement toute automatisation, du simple e-mail d'approbation à la chaîne de processus à l'échelle de l'entreprise. Ce n'est pas vrai de façon générale. La plateforme a des limites techniques et de licence claires, rarement évoquées lors des entretiens commerciaux, mais décrites assez précisément dans la documentation officielle de Microsoft.

Cet article inverse la perspective habituelle. Plutôt que de vous montrer à quoi Power Automate est adapté, il vous présente sept critères d'exclusion concrets pour lesquels un autre outil, le plus souvent Azure Logic Apps ou une solution pro-code, est le choix le plus honnête. Toutes les informations proviennent de la documentation Microsoft sur les limites de Power Automate et sur la migration vers Azure Logic Apps.

Les 7 critères d'exclusion en un coup d'œil

Si un ou plusieurs des points suivants s'appliquent à votre cas d'usage, vous devriez au moins remettre Power Automate en question de manière critique avant de le construire.

• Vous avez durablement besoin de plus de débit que ce que prévoit la plateforme. Un flux cloud unique est limité, selon les limites de Power Automate, à un maximum de 500 actions par définition de workflow, avec en plus une limite de rafale de 100 000 actions par cinq minutes sur l'ensemble des flux. Quiconque dépasse régulièrement ces limites doit découper artificiellement le processus en sous-flux au lieu de le construire simplement.
• La logique de votre workflow a besoin de code réel. Power Automate est conçu comme un outil low-code à no-code. Selon le guide de migration vers Azure Logic Apps, l'intégration personnalisée dans Power Automate est « limitée le plus souvent à aucun code ou à peu de code », tandis qu'Azure Logic Apps Standard peut exécuter directement dans le workflow ses propres fonctions .NET, scripts C# ou scripts PowerShell.
• Vous avez besoin d'une isolation réseau. Si les workflows doivent s'exécuter exclusivement au sein d'un réseau virtuel, sans aucun contact avec l'internet ouvert, Power Automate n'offre aucune solution pour cela. Selon la même documentation, Azure Logic Apps Standard prend en charge l'intégration VNet et les points de terminaison privés, contrairement à Power Automate.
• Vous avez besoin de géoredondance pour des processus critiques pour l'entreprise. Dans une comparaison directe, Microsoft décrit explicitement Power Automate comme ayant des « options de déploiement régional limitées », tandis qu'Azure Logic Apps Standard et Consumption offrent tous deux une géoredondance intégrée et un basculement automatisé sur plusieurs régions.
• Vous avez besoin d'un ALM professionnel avec un contrôle de version complet. Selon Microsoft, Power Automate dispose d'une « gestion des versions limitée ». Azure Logic Apps offre en revanche une intégration Git complète avec des pipelines CI/CD via Azure DevOps ou GitHub, y compris le suivi des modifications et le retour à des versions antérieures du workflow.
• La logique de votre processus est trop imbriquée pour être modélisée proprement. Selon la documentation sur les limites, un flux unique autorise un maximum de huit niveaux d'imbrication pour les actions et 25 cas de commutation par portée. Les processus comportant de nombreuses conditions imbriquées et chemins d'exception atteignent ces limites plus vite qu'on ne le remarque lors du prototypage.
• Vos coûts explosent à mesure que vous montez en charge. Quiconque dépasse régulièrement les limites d'actions de sa licence paie soit des licences de processus supplémentaires (150 dollars US par bot et par mois, selon la FAQ sur la licence Power Automate), soit des dépassements en paiement à l'usage. Pour un volume très élevé et prévisible, un modèle Consumption dans Azure Logic Apps peut finalement s'avérer moins cher que l'empilement de licences de processus.

Quand les limites de la plateforme sont le véritable obstacle

Le premier et le sixième critère sont étroitement liés et sont, en pratique, les plus souvent sous-estimés. La documentation sur les limites distingue les limites de conception de flux, qui s'appliquent à une définition de workflow unique, des limites de débit, qui s'appliquent à toutes les exécutions sur une période glissante. Un flux avec un contexte de licence Premium peut effectuer 40 000 requêtes Power Platform par 24 heures, un flux avec une licence de processus 250 000, cumulables jusqu'à dix fois pour atteindre 2,5 millions. Cela semble généreux, mais devient vite juste lorsqu'un flux exécute plusieurs actions en boucle pour chaque ligne d'un grand tableau : une boucle avec deux actions et 10 000 itérations consomme déjà, selon la FAQ sur la licence, plus de 20 000 actions, pour une seule exécution de flux.

Si un flux fonctionne durablement au-delà des limites, Microsoft commence par le ralentir automatiquement, puis le désactive complètement après 14 jours de dépassement continu. Ce n'est pas un risque théorique mais une réaction documentée de la plateforme. Quiconque constate dès la phase de conception qu'un processus a structurellement besoin de plus de débit devrait directement planifier avec Azure Logic Apps plutôt que de devoir migrer plus tard.

Quand Power Automate ne peut pas suivre techniquement

Les critères restants concernent davantage l'architecture que le volume. La comparaison entre Power Automate et Azure Logic Apps montre clairement que les deux plateformes, bien que reposant sur les mêmes principes de base, sont conçues pour des publics différents : Power Automate pour les développeurs citoyens et les métiers, Azure Logic Apps Standard pour les intégrateurs professionnels avec des exigences de sécurité, de scalabilité et de gouvernance au niveau de l'entreprise.

Concrètement, selon la documentation, cela signifie :

• Le contrôle d'accès basé sur les rôles fonctionne au niveau de l'utilisateur dans Power Automate, et au niveau des ressources dans Azure Logic Apps. Si le créateur d'un flux quitte l'entreprise, l'accès à ses flux dans Power Automate peut devenir plus compliqué que dans une structure basée sur les ressources.
• La gestion des erreurs dans Power Automate se limite à la vérification de l'exécution avec une liste d'erreurs dans le flux, tandis qu'Azure Logic Apps propose des notifications d'erreur dédiées et un concept « Save Failed » pour les enregistrements échoués.
• La surveillance dans Power Automate passe par le portail lui-même et une intégration optionnelle avec Application Insights, tandis qu'Azure Logic Apps offre une intégration complète avec Azure Monitor, des alertes personnalisées et une télémétrie avancée.

Aucun de ces points ne fait de Power Automate un mauvais produit, il montre simplement à quoi il n'a pas été conçu. Pour les processus départementaux, les approbations, les automatisations SharePoint ou la connexion aux services Microsoft 365, Power Automate reste généralement la solution la plus rapide et la plus économique. Mais dès que la sécurité réseau, le code personnalisé ou l'ALM d'entreprise deviennent une exigence centrale, l'étape suivante honnête est de se tourner vers Azure Logic Apps ou une solution hybride combinant les deux.

Ce que cela signifie pour votre décision

Aucun des sept critères n'est un motif d'élimination automatique, mais chacun d'eux devrait être vérifié avant la construction, pas après. La façon la plus économique de le clarifier est une brève évaluation préalable : combien d'actions le processus exécute-t-il par exécution, à quelle fréquence s'exécute-t-il, a-t-il besoin de son propre code, doit-il fonctionner de manière isolée du réseau, et à quel point la résilience sur plusieurs régions est-elle critique. Quiconque répond à ces questions avant le premier flux s'épargne une migration coûteuse par la suite.

Dans le cadre du conseil Power Automate de NordFlux, nous vérifions exactement ces points avec vous avant la création du premier flux, afin que vos collaborateurs numériques automatisent là où Power Automate est vraiment le bon choix, et que vous gardiez à tout moment le contrôle de la décision d'architecture.

Questions fréquentes

Power Automate est-il fondamentalement un mauvais choix pour les grandes entreprises ?

Non. De nombreux grands groupes utilisent Power Automate avec succès pour des processus départementaux et des automatisations métiers, souvent en parallèle d'Azure Logic Apps pour les workflows critiques pour l'entreprise, à fort volume ou sensibles en matière de sécurité. Les critères d'exclusion concernent des processus individuels, pas l'adéquation de la plateforme dans son ensemble.

Que se passe-t-il si je dépasse quand même les limites ?

Selon la documentation Microsoft, le flux concerné ralentit d'abord automatiquement dès qu'il dépasse les limites. S'il reste continuellement au-dessus des limites pendant 14 jours, Microsoft le désactive complètement. Vous pouvez ensuite le réactiver, mais vous devez le retravailler, sinon le même phénomène se reproduit.

Puis-je combiner Power Automate et Azure Logic Apps au lieu de choisir ?

Oui, c'est même fréquent en pratique. Un flux Power Automate peut appeler un workflow Azure Logic Apps et inversement. Cela permet de modéliser la partie simple, proche des métiers, d'un processus dans Power Automate, tandis que la partie à fort volume ou critique en matière de sécurité s'exécute dans Azure Logic Apps.

Une licence de processus vaut-elle la peine pour contourner les limites d'actions ?

En cas de dépassement modéré, oui, elle relève la limite quotidienne à 250 000 actions et peut être cumulée jusqu'à dix fois. Mais en cas de débit structurellement très élevé et durable, l'empilement de plusieurs licences de processus devient coûteux ; il vaut alors la peine de comparer avec le modèle tarifaire Consumption d'Azure Logic Apps.

Comment savoir tôt qu'un processus remplit l'un des critères d'exclusion ?

Le plus fiable est une courte vérification technique préalable avant la construction : nombre estimé d'actions par exécution, fréquence d'exécution attendue, exigences en matière de sécurité réseau et de disponibilité. Cette vérification préalable dépasse rarement une à deux heures, mais évite qu'un flux n'atteigne ses limites qu'après sa mise en production.