Sélecteurs robustes et temps d'attente dans Power Automate Desktop

Quand une automatisation d'interface construite avec Power Automate Desktop (PAD) échoue soudainement avec « Failed to get UI element » après des semaines en production, ce n'est presque jamais un hasard. La plupart du temps, quelque chose a changé en arrière-plan que le sélecteur ne retrouve plus : une mise à jour de l'application, une résolution d'écran différente, une fenêtre qui met désormais une seconde de plus à s'ouvrir. Ce sont précisément ces deux leviers, des sélecteurs robustes et des temps d'attente propres, qui déterminent si un flux tourne de façon stable pendant des mois en mode sans surveillance ou doit être réparé manuellement tous les quelques jours.

Ce guide vous montre comment les sélecteurs sont construits dans PAD, quels opérateurs et variables les rendent dynamiques, et comment remplacer les pauses fixes par une véritable synchronisation grâce aux bonnes actions Wait. À la fin, vous trouverez une checklist pour protéger vos flux existants contre les causes d'échec les plus fréquentes.

Pourquoi les sélecteurs se cassent

Un sélecteur dans Power Automate Desktop décrit précisément où se trouve un élément d'interface dans la hiérarchie d'une application ou d'une page web. Selon Microsoft, les sélecteurs sont créés lorsque PAD capture des propriétés comme le nom, la classe ou l'ID d'automatisation, ainsi que la position de l'élément dans la structure de l'interface. C'est justement cette capture qui rend les sélecteurs sensibles aux changements. Microsoft cite dans le guide de dépannage des flux de bureau sans surveillance notamment les facteurs suivants, qui peuvent invalider un sélecteur qui fonctionnait auparavant :

• La résolution d'écran et la mise à l'échelle DPI
• Les mises à jour de l'application ou les changements d'interface utilisateur
• La version du système d'exploitation
• La taille ou le mode de la fenêtre, par exemple maximisée par rapport à mode fenêtré
• L'état d'un élément, activé ou désactivé
• Les autorisations utilisateur, car une application peut se charger différemment selon le profil

Qui sait à quels endroits un sélecteur se casse habituellement peut le construire dès le départ pour résister à ces variations, plutôt que de réagir seulement après le premier échec.

La structure d'un sélecteur : niveaux, attributs, opérateurs

Un sélecteur se compose de plusieurs niveaux enchaînés par le caractère `>`. Chaque niveau décrit un élément avec ses attributs sous la forme `element[Attribut1="Wert1"][Attribut2="Wert2"]`. Un exemple simple issu de la documentation sur la création d'une sélection personnalisée montre une fenêtre d'éditeur : `:desktop > window[Name="Notizen.txt - Editor"][Process="Notepad"]`. Le premier niveau commence toujours par l'élément racine `:desktop`, chaque niveau suivant étant l'enfant du précédent.

Des opérateurs plutôt que des valeurs figées

L'opérateur par défaut Égal recherche une valeur exacte et figée. Cela fonctionne de manière fiable pour les applications statiques, mais devient rapidement problématique dès que les titres de fenêtre changent dynamiquement, par exemple via un nom de fichier ou un horodatage dans le titre. Power Automate propose pour cela cinq autres opérateurs :

• Différent de, vérifie toute valeur sauf une valeur précise
• Contient, trouve des éléments qui n'ont pas de motif fixe mais contiennent un mot-clé précis
• Commence par, vérifie le début d'une valeur
• Se termine par, vérifie la fin d'une valeur
• Correspondance par expression régulière, vérifie par rapport à un motif personnalisé basé sur le moteur regex .NET

Un titre de fenêtre comme « Notizen.txt - Editor (2) » peut être capturé de façon bien plus robuste avec Commence par qu'avec Égal, car le chiffre entre parenthèses à la fin peut varier sans casser le sélecteur.

Des variables pour les valeurs dynamiques

Si la valeur d'un attribut dépend d'une action précédente, par exemple un nom de fichier connu seulement à l'exécution, vous pouvez insérer une variable dans le sélecteur avec la notation pourcentage, par exemple `:desktop > window[Name="%WindowName%"][Process="Notepad"]`. Le sélecteur reste ainsi valide même si la valeur attendue change d'une exécution à l'autre.

Utiliser plusieurs sélecteurs et un mécanisme de repli

Un même élément d'interface peut posséder plusieurs sélecteurs dans PAD. Si le premier échoue, Power Automate passe automatiquement au suivant dans l'ordre défini, sans étape supplémentaire à programmer dans votre flux. Grâce au bouton Sélection avec nouvelle capture ou en copiant un sélecteur existant, vous pouvez créer des variantes supplémentaires, par exemple une avec Égal pour le cas normal et une avec Contient ou Regex comme niveau de repli.

Pour les interfaces particulièrement instables, comme les sessions de terminal ou les applications héritées sans hiérarchie d'interface propre, Microsoft recommande dans le même guide un repli sur image, où PAD s'appuie sur la reconnaissance d'image plutôt que sur les attributs d'interface lorsqu'aucun sélecteur classique ne fonctionne plus.

Des temps d'attente réels plutôt que des pauses fixes

Les actions « Wait » fixes avec un nombre de secondes défini sont une cause fréquente de flux qui tournent inutilement lentement ou qui accèdent quand même trop tôt à un élément. Power Automate Desktop propose pour cela des actions de synchronisation dédiées, qui attendent l'état réel de l'application plutôt que de laisser passer aveuglément une durée fixe.

• Attendre une fenêtre met l'exécution en pause jusqu'à ce qu'une fenêtre précise s'ouvre, se ferme, obtienne le focus ou le perde. La recherche peut se faire via un élément d'interface, via l'instance ou le handle, ou via le titre et la classe.
• Attendre le contenu de la fenêtre met en pause jusqu'à ce qu'un texte précis ou un élément d'interface apparaisse ou disparaisse dans une fenêtre, avec en option une vérification si l'élément est activé ou désactivé. C'est exactement cette action que Microsoft recommande dans la référence des actions d'automatisation de l'interface utilisateur, lorsqu'un élément d'interface n'est pas encore disponible au moment de l'exécution.
• Attendre une image attend qu'une image apparaisse ou disparaisse à l'écran ou dans la fenêtre au premier plan, avec une tolérance réglable et un choix entre correspondance d'image simple et avancée.

Les trois actions peuvent être configurées pour échouer avec une erreur de délai d'attente après un temps défini, plutôt que d'attendre indéfiniment. C'est important pour les flux sans surveillance, afin qu'une fenêtre bloquée n'immobilise pas l'ensemble de l'exécution, mais passe de façon contrôlée dans la gestion des erreurs.

Tester et réparer les sélecteurs

Avant qu'un flux ne passe en fonctionnement sans surveillance, il vaut la peine de tester chaque sélecteur critique directement dans le Selector Builder. Si un sélecteur se casse quand même, la fonction « Réparer le sélecteur » offre une aide rapide : vous recapturez l'élément par Ctrl+clic gauche, PAD compare l'ancienne structure avec la nouvelle et propose une sélection réparée, que vous pouvez encore vérifier avant de l'accepter. Si un sélecteur contient des variables, la réparation automatique ne fonctionne pas selon Microsoft, seule reste alors l'adaptation manuelle dans l'éditeur de texte du Selector Builder.

Checklist pour des flux stables en mode sans surveillance

Pour les flux destinés à tourner durablement sans surveillance, Microsoft résume plusieurs recommandations qui ont fait leurs preuves dans la pratique :

• Enregistrer plusieurs sélecteurs par élément pour qu'un mécanisme de repli puisse intervenir
• Construire des sélecteurs avec des attributs statiques et capturer les parties dynamiques via des opérateurs ou des variables
• Utiliser le repli sur image là où les attributs d'interface ne sont pas assez fiables
• Mettre en place une politique de nouvelle tentative dans la gestion des erreurs de chaque action critique
• Choisir le bon type d'action, automatisation web pour les éléments web, automatisation d'interface pour les éléments de bureau
• S'assurer que l'application démarre dans le même mode de fenêtre en mode sans surveillance qu'au test surveillé
• Recapturer et tester le sélecteur directement sur la machine sans surveillance

Avec cette combinaison de sélecteurs robustes et de véritables conditions d'attente, un flux tombe bien plus rarement dans le vide. Vous gardez le contrôle du déroulement, car chaque action ne démarre que lorsque l'application est réellement prête, plutôt que de se lancer au petit bonheur après un temps d'attente estimé. Quiconque utilise Power Automate Desktop de façon productive à plus grande échelle devrait intégrer ces mesures de stabilité dès le départ, par exemple dans le cadre de projets d'automatisation accompagnés, plutôt que de les rattraper après les premières pannes nocturnes.

Questions fréquentes

Pourquoi une simple action « Wait » avec un nombre de secondes fixe ne suffit-elle pas ?

Un temps d'attente fixe ne fait qu'estimer combien de temps une application a besoin, sans réagir à son état réel. Si l'application est plus rapide, le flux perd du temps inutilement ; si elle est plus lente, par exemple à cause de la charge réseau ou d'un serveur lent, l'action suivante tente d'accéder à un élément qui n'est pas encore là. Des actions comme Attendre le contenu de la fenêtre ou Attendre une fenêtre vérifient au contraire l'état réel de l'application et ne poursuivent que lorsque la condition est réellement remplie.

Quelle est la différence entre « Attendre une fenêtre » et « Attendre le contenu de la fenêtre » ?

Attendre une fenêtre concerne la fenêtre dans son ensemble, c'est-à-dire si elle s'ouvre, se ferme, obtient le focus ou le perd. Attendre le contenu de la fenêtre va un niveau plus loin et vérifie si, à l'intérieur d'une fenêtre déjà ouverte, un texte précis ou un élément d'interface précis apparaît, disparaît ou change d'état activé ou désactivé. En pratique, vous combinez souvent les deux : d'abord attendre la fenêtre, puis le contenu concret.

Combien de sélecteurs dois-je créer par élément d'interface ?

Il n'y a pas de nombre fixe, mais Microsoft recommande explicitement d'enregistrer plusieurs sélecteurs par élément afin qu'un mécanisme de repli intervienne si le premier échoue. En pratique, deux à trois variantes suffisent pour la plupart des éléments, par exemple une avec Égal pour le cas normal, une avec Contient ou Regex comme niveau de repli, et pour des interfaces particulièrement instables, un repli sur image supplémentaire.

Puis-je faire réparer automatiquement un sélecteur contenant des variables ?

Non. Selon la documentation Microsoft, la fonction de réparation automatique ne fonctionne pas pour les sélecteurs contenant une ou plusieurs variables. Dans ce cas, vous devez soit remplacer temporairement les variables par des valeurs statiques pour utiliser la réparation, soit ajuster le sélecteur directement à la main dans l'éditeur de texte du Selector Builder.

Que faire si un sélecteur continue de se casser malgré la réparation et le repli ?

Si même un sélecteur réparé avec plusieurs niveaux de repli ne tourne pas de façon stable, passer au repli sur image ou à l'automatisation de surface avec des actions de souris, de clavier et d'OCR aide souvent, selon Microsoft, en particulier pour les applications sans hiérarchie d'interface propre, par exemple dans des environnements de bureau virtuel. Il vaut également la peine d'examiner la cause sous-jacente : il s'agit souvent d'une différence de résolution d'écran, de mise à l'échelle DPI ou de mode de fenêtre entre l'environnement de développement et la machine cible sans surveillance.