Power Automate Desktop (RPA) : quand automatiser un poste de travail plutôt qu'une API

Power Automate Desktop (RPA) se justifie quand il n'existe aucune API ni connecteur officiel pour piloter une application - un vieux logiciel métier, un ERP sans interface programmable, un site web tiers fermé - et qu'il faut reproduire des actions humaines directement sur l'écran. Dès qu'une API, un connecteur premium ou Dataverse est disponible, un cloud flow classique reste toujours le choix le plus stable, le plus simple à monitorer et le moins coûteux à maintenir sur la durée. Le vrai risque de terrain, ce n'est pas de mal choisir une fois, c'est de garder du RPA en place trois ans après que l'éditeur a enfin sorti une API.

La question à se poser avant tout script d'automatisation

Avant de lancer un enregistreur d'actions dans Power Automate Desktop, une seule question mérite d'être tranchée : existe-t-il un moyen d'interagir avec le système cible autrement qu'en pilotant son interface graphique ? Un connecteur natif ou premium, une API REST documentée, un accès direct à la base de données ou à Dataverse doivent systématiquement être envisagés en premier, car ils ne dépendent pas de l'apparence visuelle de l'application et survivent à une mise à jour d'interface.

Le RPA - qu'il s'agisse de Power Automate Desktop, d'UiPath ou d'un autre outil du marché - n'est pas une solution de repli par défaut : c'est une réponse à une contrainte réelle, celle de l'absence d'interface programmable. Le confondre avec une simplicité de mise en œuvre ("pas besoin de développeur, on enregistre les clics") coûte cher en maintenance dès que l'application cible évolue.

Ce que Power Automate Desktop fait bien

Une fois la contrainte d'absence d'API confirmée, Power Automate Desktop couvre efficacement plusieurs scénarios récurrents en entreprise : la saisie répétitive dans un ERP ancien sans web services exposés, le pilotage d'applications legacy accessibles uniquement via Citrix ou un émulateur terminal, l'extraction de données depuis des PDF ou des interfaces web sans API (combinée à AI Builder pour la reconnaissance de documents), ou encore la bascule de données entre deux systèmes qui n'ont jamais été prévus pour communiquer entre eux.

Les flows desktop peuvent tourner en mode attended, sur le poste d'un utilisateur qui déclenche et supervise l'exécution, ou en mode unattended, sur une machine dédiée qui exécute le flow sans supervision humaine - typiquement la nuit ou en tâche de fond. Le mode unattended est celui qui rapproche le plus Power Automate Desktop d'un outil RPA au sens strict, avec les mêmes exigences d'infrastructure que ses concurrents du marché.

Les pièges de terrain du unattended

C'est sur le mode unattended que se concentrent la plupart des retours d'expérience négatifs. Trois problèmes reviennent le plus souvent : la fragilité aux changements d'interface (un bouton déplacé de quelques pixels ou un nouveau pop-up de consentement suffit à casser un flow qui tournait sans incident depuis des mois), la gestion de session (une machine virtuelle qui se verrouille, un profil qui se déconnecte, une mise à jour Windows qui redémarre le poste en pleine exécution), et le stockage des identifiants utilisés pour se connecter aux applications cibles, qui doit être encadré au même niveau de rigueur que n'importe quel compte de service.

Le monitoring est également moins mature que sur les cloud flows : un flow desktop qui échoue silencieusement sur une machine dédiée, sans alerte configurée explicitement, peut rester en panne plusieurs jours avant d'être détecté - le même angle mort que celui des flows cloud qui échouent sans notification, mais avec une infrastructure supplémentaire à surveiller.

Tableau comparatif : cloud flow vs desktop flow (RPA)

Critère	Cloud flow	Desktop flow (RPA)
Mode d'interaction	API, connecteur, Dataverse	Pilotage de l'interface graphique
Fiabilité dans le temps	Stable, indépendante du rendu visuel	Sensible aux évolutions d'interface
Infrastructure requise	Aucune (cloud managé)	Poste ou VM dédiée pour le unattended
Licence	Standard ou premium selon connecteurs	Add-on RPA attended ou unattended en plus
Monitoring et alerting	Natif, centralisé dans Power Platform	Plus limité, à renforcer manuellement
Cas d'usage type	Systèmes avec API ou connecteur disponible	Applications legacy, Citrix, sans API
Coût de maintenance	Faible à modéré	Plus élevé, révisions fréquentes nécessaires

Architecture hybride : faire coexister cloud et desktop flows

Dans la pratique, les deux approches se combinent plus souvent qu'elles ne s'opposent. Le schéma le plus robuste consiste à laisser un cloud flow orchestrer l'ensemble du processus - réception de la donnée, règles métier, notifications, écriture dans Dataverse ou SharePoint - et à ne déclencher un flow desktop que pour l'unique étape qui exige de piloter une interface sans API. Le cloud flow encapsule cet appel dans un scope avec gestion d'erreur dédiée, journalise le résultat, et déclenche une alerte en cas d'échec plutôt que de laisser l'étape RPA échouer dans l'angle mort.

Cette architecture limite la surface fragile du processus au strict minimum : seule l'étape sans alternative technique passe par le RPA, tout le reste bénéficie de la stabilité et de la traçabilité d'un cloud flow classique.

Les erreurs les plus courantes observées sur le terrain

• Choisir le RPA par facilité de prise en main alors qu'une API ou un connecteur premium existe déjà pour le même système - créant une dette technique évitable dès la conception.
• Déployer du unattended sur un poste partagé ou une session RDP non dédiée, provoquant des conflits de session et des échecs difficiles à diagnostiquer.
• Ne pas encadrer le stockage des identifiants utilisés par les flows desktop dans l'Automation Center, avec le même niveau d'exigence qu'un compte de service classique.
• Sous-estimer le coût de maintenance récurrent lié aux évolutions d'interface des applications pilotées, qui n'apparaît qu'après plusieurs mois de production.
• Ne pas configurer d'alerte explicite en cas d'échec, alors même que le mode unattended tourne justement sans supervision humaine directe.

Questions fréquentes

Power Automate Desktop remplace-t-il un outil RPA dédié comme UiPath ou Automation Anywhere ?

Pour une organisation déjà sous licence Microsoft 365 ou Power Platform, Power Automate Desktop couvre la plupart des scénarios RPA courants sans coût de licence dédié additionnel pour le mode attended. Les outils RPA spécialisés restent pertinents pour des besoins très avancés (orchestration de flottes de bots à grande échelle, bibliothèques de composants métier préconstruits) ou dans des environnements déjà largement équipés avec un autre outil.

Le mode unattended nécessite-t-il forcément une machine virtuelle dédiée ?

En pratique oui, dès qu'il s'agit d'une exécution en production fiable : une machine partagée avec des sessions concurrentes multiplie les risques de conflit et de verrouillage. Une VM dédiée, correctement dimensionnée et isolée, reste la configuration recommandée pour du unattended en environnement de production.

Comment sécuriser un flow RPA qui manipule des identifiants sensibles ?

Les identifiants doivent être stockés via les mécanismes prévus par l'Automation Center (gestionnaire d'identifiants chiffré), jamais en clair dans les étapes du flow, et le compte utilisé doit suivre le même principe de moindre privilège qu'un compte de service classique, avec une revue périodique des accès qu'il détient.