Le Recorder dans Power Automate Desktop : fonctionnement et limites honnêtes

Peu de fonctionnalités abaissent autant la barrière d'entrée dans Power Automate Desktop que le Recorder. Au lieu de glisser les actions une par une depuis la liste d'actions et de remplir les paramètres à la main, tu cliques simplement à travers le processus que tu veux automatiser, et le Recorder traduit chaque mouvement de souris et de clavier en une action de flux prête à l'emploi. Pour des séquences de clics récurrentes dans des programmes familiers, c'est souvent le moyen le plus rapide d'obtenir un premier brouillon fonctionnel.

Mais l'autre moitié honnête de l'histoire est tout aussi importante : le Recorder n'est pas un outil qui comprend fiablement chaque interface, et il ne remplace pas le travail de retouche. Cet article montre comment le Recorder fonctionne techniquement, ce qu'il couvre au-delà des simples clics, et où, selon la documentation de Microsoft elle-même, il atteint des limites claires, en particulier avec des interfaces utilisateur complexes ou construites de façon inhabituelle.

Ce que le Recorder enregistre et comment il le fait

Tu trouves le Recorder directement dans la barre d'outils du concepteur de flux. Un clic sur Recorder ouvre la fenêtre d'enregistrement, un autre clic sur Enregistrer démarre la capture. À partir de ce moment, le Recorder suit ton activité de souris et de clavier par rapport aux éléments d'interface concernés et convertit chaque action en une étape distincte. Pendant l'enregistrement, un marqueur de texte affiche brièvement le message « En attente d'une action » jusqu'à ce que le clic soit effectivement capturé et inséré, un petit signal mais pratique t'indiquant de ne pas cliquer trop vite.

Un clic droit sur un élément ouvre par ailleurs un menu contextuel avec les actions disponibles pour cet élément, comme définir une valeur de liste déroulante ou extraire du texte. Dès que tu termines l'enregistrement avec Terminé, Power Automate convertit automatiquement les étapes enregistrées en actions de flux de bureau et enregistre tous les éléments utilisés dans le panneau des éléments d'interface, afin que tu puisses les réutiliser plus tard. Tu trouveras plus de détails dans la documentation Microsoft sur l'enregistrement des flux de bureau.

UIA et MSAA : deux modes de capture pour différents programmes

Toutes les applications Windows ne fournissent pas la même qualité d'informations d'accessibilité, c'est pourquoi le Recorder propose deux modes de capture. UI Automation (UIA) est le framework moderne recommandé par Microsoft et fonctionne particulièrement bien avec les applications construites en WPF, WinForms ou UWP ; il fournit des informations d'éléments plus détaillées et une hiérarchie plus stable. Microsoft Active Accessibility (MSAA) est plus ancien et intervient là où les applications ne fournissent pas d'éléments UIA, par exemple les programmes classiques Win32 ou VB6. Tu choisis le mode approprié via le menu « Mode d'enregistrement » du Recorder, selon l'application que tu automatises.

Plus que de simples clics : ce que le Recorder couvre également

Le Recorder ne se limite pas à de simples clics de souris, il couvre spécifiquement toute une série de schémas d'interface récurrents :

• Listes déroulantes : Dès que tu sélectionnes une liste déroulante, le Recorder ouvre son propre écran où tu définis la valeur souhaitée, voire plusieurs en cas de sélection multiple. À l'exécution, Power Automate sélectionne automatiquement cette valeur.
• Sélecteurs de date et de couleur : Pour les champs de saisie HTML de type date, datetime-local, month, time ou week, ainsi que pour les sélecteurs de couleur, le Recorder ouvre un champ de texte dans lequel tu saisis la valeur souhaitée au format approprié.
• Éditeurs de méthode d'entrée (IME) : Pour les langues qui ne peuvent pas être saisies directement avec un clavier QWERTY, tu peux faire un clic droit sur « Remplir le champ de texte » pour saisir du texte via un IME.
• Lancement du navigateur de trois façons : Tu peux démarrer un nouveau navigateur spécifiquement via le menu du Recorder (Edge, Chrome, Firefox, Internet Explorer), commencer l'enregistrement dans un navigateur déjà ouvert, ou ouvrir le navigateur manuellement via un raccourci, ce que le Recorder enregistre alors comme sa propre action d'automatisation d'interface.

Enregistrement basé sur l'image : le Recorder pour les applications difficiles

Certaines applications n'exposent pas du tout leur API d'accessibilité ou présentent d'autres obstacles techniques, si bien que le Recorder classique ne peut capturer aucune action. C'est précisément pour ce cas que Power Automate propose l'enregistrement basé sur l'image : au lieu de détecter les éléments d'interface via des sélecteurs, ce mode fonctionne avec la reconnaissance d'image et la reconnaissance optique de caractères (OCR). Un clic sur un élément crée automatiquement un extrait d'image avec un nom modifiable, et via « Extraire le texte de l'image », tu peux en plus sélectionner une zone de texte ainsi qu'une zone d'ancrage stable à proximité, à partir de laquelle le texte est lu par le moteur OCR Tesseract.

Les limites honnêtes : où le Recorder atteint ses limites

C'est précisément ici qu'il vaut la peine de regarder les problèmes connus documentés par Microsoft lui-même, car ils montrent que le Recorder fait délibérément des compromis et n'est pas une solution miracle.

Limitations documentées du Recorder

• Les étapes issues du menu Démarrer de Windows ou de la barre des tâches peuvent ne pas être entièrement enregistrées, et Microsoft n'indique explicitement aucune solution pour cela.
• Dans les flux enregistrés par image, le clic peut atterrir au mauvais endroit à l'exécution ; comme correction, Microsoft recommande d'abaisser la valeur de tolérance de l'action générée automatiquement « Déplacer la souris vers l'image » dans les paramètres avancés.
• La fenêtre contextuelle pour « Extraire le texte de l'image » peut se cacher derrière la fenêtre contextuelle de l'application elle-même ; un clic droit ailleurs sur l'écran permet de résoudre ce problème.
• Les frappes clavier envoyées via l'enregistrement basé sur l'image à une fenêtre RDP maximisée n'arrivent parfois pas du tout, c'est pourquoi Microsoft recommande de réduire la fenêtre RDP pour qu'elle ne remplisse pas tout l'écran.
• Le glisser-déposer n'est que partiellement pris en charge : le Recorder enregistre de façon fiable des actions comme déplacer une fenêtre ou redimensionner une fenêtre, mais actuellement pas l'action « Élément d'interface de glisser-déposer d'une fenêtre ».

Quand le Recorder ou le sélecteur d'éléments ne voient rien du tout

Cela devient encore plus fondamental lorsque le Recorder ou le sélecteur d'éléments ne peuvent pas du tout capturer une application. Selon le guide de dépannage Microsoft pour l'automatisation d'interface, il existe deux causes typiques à cela. Premièrement, des processus d'arrière-plan gênants comme le Microsoft Accessory Center ou DesktopBridge peuvent complètement bloquer l'automatisation d'interface ; il est utile ici de mettre fin à ces processus et de les désactiver durablement. Deuxièmement, et nettement plus difficile à contourner, certaines applications de bureau utilisent leurs propres frameworks d'interface ou méthodes de rendu, incompatibles avec les API d'accessibilité standard sur lesquelles Power Automate s'appuie. Pour le Recorder, ces éléments restent alors simplement invisibles.

Microsoft cite quatre solutions de contournement pour ce cas : déplacer la souris vers l'image, déplacer la souris vers du texte à l'écran via OCR, faire fonctionner le Recorder avec des coordonnées codées en dur, ou combiner directement les actions de souris et de clic via des coordonnées fixes. Il est important de noter l'avertissement explicite de la documentation à ce sujet : pour que les solutions basées sur les coordonnées fonctionnent de façon fiable, la résolution d'écran, les paramètres DPI et la mise à l'échelle doivent correspondre exactement à la configuration du développement au moment de l'exécution, et même de petites modifications de l'interface de l'application peuvent rendre l'étape d'automatisation inutilisable. Microsoft recommande donc explicitement de tester en profondeur de tels flux sur chaque machine cible avant de les mettre en production.

Une image comme bouée de sauvetage, avec ses propres limites

Pour des éléments d'interface individuels, tu peux en outre enregistrer une image comme mécanisme de secours qui intervient automatiquement lorsque le sélecteur habituel ne trouve plus un élément à l'exécution. Ce mécanisme de filet de sécurité a lui aussi des limites claires : il n'est pas pris en charge pour l'extraction de données et l'extraction de données web, ni pour des actions comme « Si la fenêtre contient » ou « Attendre le contenu de la page web » si la condition « Contient du texte » ou « Ne contient pas de texte » y est configurée. Et quiconque ouvre et enregistre un flux avec un secours par image dans une version de Power Automate Desktop jusqu'à la v2.44 incluse perd définitivement le sélecteur d'image ; selon Microsoft, aucune récupération n'est alors possible dans ce cas.

Le Recorder comme squelette, pas comme résultat final

Microsoft le formule avec une sobriété agréable dans sa propre documentation : le Recorder doit fournir la charpente de base d'un flux, la plupart des processus enregistrés devant ensuite être retravaillés pour fonctionner vraiment de façon fiable. Certains types d'actions, comme les conditions et les boucles, ne peuvent fondamentalement pas être enregistrés du tout et doivent être ajoutés manuellement par la suite. C'est exactement à ce moment-là qu'un flux qui fonctionne une fois en test se distingue d'un flux qui tourne encore de façon fiable des mois plus tard.

Que tu utilises le Recorder toi-même pour de premiers brouillons ou que tu fasses construire toute une collaboratrice numérique sur la base de Power Automate, tu gardes en fin de compte le contrôle sur les clics qui restent réellement automatisés, sur les sélecteurs suffisamment robustes pour la production, et sur les cas où un secours par image ou une solution OCR représente plus un risque qu'une sécurité.

Questions fréquentes

Le Recorder peut-il enregistrer n'importe quelle application ?

Non. Par défaut, le Recorder ne fonctionne qu'avec les applications qui exposent leurs éléments via UIA ou MSAA. Si une application n'expose pas du tout son API d'accessibilité, l'enregistrement basé sur l'image intervient comme solution de secours, mais même celui-ci échoue parfois complètement avec des interfaces au rendu personnalisé ou fortement adaptées.

Quelle est la différence entre UIA et MSAA ?

UIA est le framework le plus moderne, recommandé par Microsoft, avec des informations d'éléments plus détaillées, adapté à la plupart des applications Windows actuelles. MSAA est plus ancien et est surtout nécessaire pour les logiciels hérités qui ne fournissent pas d'éléments UIA, comme les programmes classiques VB6 ou Win32. Le mode approprié dépend uniquement de l'application cible, pas d'une préférence personnelle.

Pourquoi le Recorder ne voit-il soudainement plus d'éléments ?

C'est généralement l'une de deux causes : des processus d'arrière-plan gênants comme le Microsoft Accessory Center ou DesktopBridge, qui peuvent être arrêtés, ou un framework d'interface de l'application cible incompatible avec les API d'accessibilité standard. Dans le second cas, seule une solution basée sur les coordonnées ou l'image reste souvent possible comme contournement.

Dois-je toujours retravailler un flux enregistré ?

En pratique, presque toujours, et Microsoft le dit lui-même. Le Recorder fournit une charpente de base fonctionnelle, mais les conditions, les boucles et une gestion des erreurs plus robuste ne peuvent pas être enregistrées et doivent ensuite être ajoutées manuellement dans le concepteur de flux.

Quelle est la fiabilité de l'enregistrement basé sur l'image en production ?

Seulement aussi fiable que l'environnement d'écran dans lequel il s'exécute. La résolution, les paramètres DPI et la mise à l'échelle doivent correspondre exactement à l'environnement de développement au moment de l'exécution, sinon le clic rate sa cible. Quiconque utilise des étapes basées sur l'image en production devrait les combiner spécifiquement avec un secours par image pour des éléments individuels et tester sur chaque machine cible avant le déploiement.