Automatiser la saisie de données dans les systèmes centraux hérités avec Power Automate for desktop — Remplacer la saisie manuelle depuis Excel et le papier par l'automatisation de l'interface utilisateur

« Chaque jour, le personnel ressaisit à la main, dans notre système de gestion des ventes interne, les commandes reçues via un formulaire web ou par e-mail. » « Transcrire dans le système central les données Excel d’un mois de présences et de demandes prend deux journées entières en fin de mois. » Nous recevons régulièrement ce type de témoignages. Ce qu’ils ont en commun, c’est que le système de destination est une ancienne application métier utilisée depuis dix ou vingt ans — un écran de l’époque WinForms ou VB6, un client dédié — sans API ni fonction d’importation CSV.

Modifier le système résoudrait le problème à la racine, mais il n’est pas rare que la saisie manuelle perdure parce que le fournisseur d’origine n’existe plus, que le code source a disparu, ou que le coût de la modification ne se justifie pas. Un outil pratique pour combler cet écart est l’automatisation de l’interface utilisateur avec Power Automate for desktop (PAD). Comme elle reproduit tout simplement la saisie au clavier et les opérations à la souris qu’une personne effectuerait, elle permet d’automatiser le travail sans toucher au système de destination. Sur Windows 11, il y a en plus la commodité de pouvoir l’essayer sans installation supplémentaire.

Cela dit, l’automatisation de l’interface utilisateur est aussi un outil pour lequel « le faire fonctionner la première fois est facile, mais le faire fonctionner de manière stable sur la durée est difficile ». Cet article se concentre sur la saisie de données et couvre tout, depuis la question de savoir si l’automatisation de l’interface utilisateur est le bon choix au départ, jusqu’à la frontière entre ce qui est gratuit et ce qui nécessite une licence, la conception pour un fonctionnement stable, et la récupération en cas d’échec. Nous avons traité la question générale de l’usage de chaque brique de Power Automate et de la gestion des erreurs dans « Automatiser les processus métier avec Power Automate — Flux cloud, flux de bureau et gestion robuste des erreurs » ; cet article-ci est le cas particulier appliqué à la saisie de données.

1. La conclusion, d’abord

• L’automatisation de l’interface utilisateur est le dernier recours. Avant d’y recourir, cherchez si le système de destination propose une importation CSV, une insertion directe en base de données, une API ou une intégration par fichier. S’il existe ne serait-ce qu’une seule de ces options, elle sera plus fiable et plus stable que l’automatisation de l’interface utilisateur.
• PAD est intégré en standard à Windows 11, et peut aussi être installé gratuitement sur Windows 10. Avec l’enregistreur et plus de 400 actions, vous pouvez construire sans code un flux qui lit Excel et saisit les données à l’écran.¹²
• Créer un flux et l’exécuter soi-même (exécution assistée) ne coûte rien de plus. Cela vaut que vous vous connectiez avec un compte professionnel ou scolaire ou avec un compte Microsoft. Le lancement automatique depuis un flux cloud, l’exécution planifiée et le partage de flux, en revanche, nécessitent tous une licence Power Automate Premium.³⁴
• L’exécution sans surveillance (unattended) — celle que vous utiliseriez pour un traitement de nuit — nécessite en plus l’enregistrement de la machine et une licence Power Automate Process. Il existe aussi des prérequis techniques propres à ce mode, comme l’obligation que tous les utilisateurs soient déconnectés.⁵⁶
• Les clés d’un fonctionnement stable tiennent en trois points : la façon de construire les sélecteurs, l’attente des éléments et la gestion des erreurs enregistrement par enregistrement. Un flux construit uniquement à coups d’actions Wait fixes finira forcément par se casser.⁷⁸⁹
• Pour pouvoir savoir jusqu’où la saisie est allée en cas d’échec, intégrez dès le départ une conception où le fichier Excel source comporte une colonne de statut et une colonne de numéro d’enregistrement, réécrites après chaque ligne. Ainsi, relancer le flux ne provoque jamais de doubles saisies.
• Comme la fatalité de finir par se casser lorsque l’écran change ne disparaît jamais, un volume important, un travail qui ne tolère aucune interruption, ou une application cible mise à jour fréquemment relèvent du développement d’intégration de données ou de la modification du système central. Nous précisons où tracer cette limite au chapitre 8.

2. Ce qui pose vraiment problème dans la saisie de données

Transcrire des données depuis Excel ou du papier vers un système central pose des problèmes qui vont bien au-delà du simple « temps perdu sur une tâche répétitive ». Trois problèmes reviennent sans cesse dans les consultations que nous recevons.

• Le temps se concentre autour de la date de clôture. La saisie quotidienne des commandes reste au moins répartie dans le temps, mais le traitement des factures de fin de mois et le décompte des présences finissent concentrés sur un ou deux jours juste après la clôture. Pendant cette période, le personnel ne peut quasiment rien faire d’autre. La plupart des entreprises absorbent sans doute cela avec des heures supplémentaires ou du renfort.
• Les erreurs de saisie se propagent en aval. Une faute de frappe sur un chiffre, une ligne décalée, un code produit confondu. Les erreurs de transcription ne sont découvertes qu’une fois transformées en facture erronée ou en quantité de stock fausse, si bien que l’effort d’investigation et de correction finit par représenter plusieurs fois l’effort de l’erreur initiale. Ajouter une double vérification réduit les erreurs, mais augmente d’autant le temps nécessaire.
• Le travail devient l’affaire d’une seule personne. Un savoir-faire du type « cet écran génère une erreur si l’on ne saisit pas dans cet ordre » ou « ce client particulier nécessite une saisie spéciale » s’accumule dans la tête de la personne en charge, et l’activité s’arrête dès qu’elle est absente.

La valeur de l’automatisation ne se limite pas au gain de temps. Un flux ne saisit jamais que de la manière qui lui a été indiquée, donc les erreurs de transcription disparaissent, et comme la procédure est conservée sous une forme tangible — le flux lui-même — cela atténue aussi le problème de dépendance à une seule personne. Pouvoir aplatir le pic autour de la date de clôture compte également beaucoup.

Notez que si la source est du papier ou un fax, une étape de « lecture » doit intervenir en amont — l’OCR des bons de commande reçus par fax, par exemple, est un sujet à part entière. Cet article part du principe que la source est déjà sous forme de données, comme un fichier Excel.

3. Les options d’automatisation — l’automatisation de l’interface utilisateur en dernier recours

La première chose à souligner, c’est que l’automatisation des opérations à l’écran (automatisation de l’interface utilisateur) est la dernière option de la liste. Elle dépend de « contraintes d’affichage » — mise en page de l’écran, résolution, temps de réponse — si bien que, aussi soigneusement construite soit-elle, elle reste inévitablement plus fragile qu’une méthode qui transmet les données directement. Vérifiez d’abord si le système central de destination propose l’une des options suivantes.

L’autre option consiste à aller dans le sens de « supprimer » la transcription elle-même, c’est-à-dire modifier ou reconstruire le système central. Nous traitons des décisions comme ajouter une fonction d’importation à une application VB6, ou aller jusqu’à une reconstruction web du front-end de saisie des commandes, dans « Combien de temps les applications VB6 vont-elles encore fonctionner ? — État du support d’exécution et un chemin pratique vers la migration vers .NET » et « Quand ne pas migrer une application Windows vers le web : un tableau de décision et la réponse pratique de la scission ». Comme la modification consomme un budget de développement, il est aussi réaliste d’automatiser d’abord avec PAD pour gagner du temps, puis d’investir dans la modification une fois que le volume de travail augmente et que les limites de l’automatisation deviennent visibles.

4. Les bases de Power Automate for desktop

Le démarrage ne demande pas grand-chose

PAD est intégré en standard à Windows 11. Recherchez « Power Automate » dans le menu Démarrer : l’application apparaît, et au premier lancement, elle se télécharge automatiquement et vous êtes prêt à l’utiliser.² Windows 10 et Windows Server 2016 bénéficient également des droits d’utilisation, et vous pouvez l’installer gratuitement depuis le centre de téléchargement.² Il existe deux méthodes d’installation — une version Microsoft Store et une version avec un installeur MSI — et si vous envisagez déjà l’intégration cloud (enregistrement de machine) évoquée plus loin, choisissez la version MSI, car elle permet d’installer en même temps l’application d’exécution de machine.¹⁰

Construire le squelette avec l’enregistreur

PAD dispose d’un enregistreur qui enregistre vos opérations et les convertit en une séquence d’actions. Il enregistre les opérations de la souris et du clavier en relation avec les éléments d’interface, ce qui le rend parfaitement pratique pour construire le squelette d’un flux de saisie de données. Ce qui compte particulièrement pour la saisie de données, c’est que vous pouvez choisir entre deux méthodes d’enregistrement, UIA (UI Automation) et MSAA (Microsoft Active Accessibility). UIA est la méthode recommandée pour les applications relativement récentes comme WPF ou WinForms, tandis que MSAA est la méthode pour les anciennes applications — comme VB6 ou le Win32 classique — dont UIA ne parvient pas à capter les éléments. Si les éléments d’un écran d’un ancien système central ne se laissent pas bien saisir, basculer le mode d’enregistrement de l’enregistreur vers MSAA peut parfois résoudre le problème.¹¹

Cela dit, l’enregistreur ne sert qu’au squelette. Il ne peut pas enregistrer les branchements conditionnels ni les boucles, donc l’hypothèse est que vous finaliserez le flux en l’éditant ensuite dans le concepteur.¹¹

Éléments d’interface et sélecteurs

PAD mémorise les boutons et les zones de texte à l’écran comme des « éléments d’interface ». Ce que c’est réellement, en dessous, c’est un sélecteur qui identifie l’élément par une combinaison de la hiérarchie des fenêtres et de ses attributs. La durée de vie d’un flux de saisie de données dépend presque entièrement de la qualité de construction de ces sélecteurs. Si un sélecteur contient un index séquentiel ou un identifiant qui change dynamiquement, il peut soudainement cesser de fonctionner un jour, alors même que l’écran a l’air identique. Remplacez les attributs dont la valeur change de Equals par Contains ou une expression régulière, configurez des sélecteurs de secours en repli pour les opérations importantes, et utilisez la fonction Repair Selector pour générer des candidats de réparation lorsqu’un sélecteur se casse. C’est la même approche de base que celle décrite dans le guide général.⁷

Il y a une précaution propre à la saisie de données. Les actions d’automatisation de l’interface utilisateur fonctionnent en partant du principe que la fenêtre cible est au premier plan, et si ce n’est pas le cas, elles la ramènent automatiquement au premier plan.¹² Autrement dit, le PC qui exécute le flux est, de fait, « réservé exclusivement au flux ». Évitez de faire tourner le flux sur un PC où le personnel effectue simultanément d’autres tâches, car c’est la recette parfaite pour des clics et des saisies parasites.

La forme de base de la saisie de données : lire depuis Excel, écrire à l’écran

La forme de base d’un flux de saisie de données est « lire avec une action Excel → boucler et écrire un enregistrement à la fois par des opérations d’interface ». Ouvrez le fichier avec Launch Excel, et lisez une plage avec Read from Excel worksheet, qui devient une variable de type table de données. Activer l’option « première ligne comme noms de colonnes » vous permet ensuite de référencer les valeurs par nom de colonne dans la boucle, comme CurrentItem['CodeClient'], ce qui rend le flux plus résistant à un réordonnancement des colonnes.¹³ Utilisez Write to Excel worksheet pour réécrire les résultats. Si vous voulez ajouter à la fin des lignes, vous pouvez localiser une ligne vide avec Get first free row on column.¹³

5. Ce qui est gratuit et où se situe la frontière de licence

La question qui revient toujours au moment de décider d’adopter PAD est : « jusqu’où est-ce gratuit, et à partir de quand cela devient-il payant ? » La frontière se situe entre « le construire et l’exécuter à la main » et « le faire s’exécuter automatiquement et le gérer à l’échelle de l’organisation ».

Construire des flux et les exécuter manuellement ne coûte rien de plus, quel que soit le type de compte.³⁴ Avec un compte Microsoft, les flux sont enregistrés sur OneDrive ; avec un compte professionnel ou scolaire, ils sont enregistrés dans Dataverse de l’environnement par défaut. Si vous utilisez cela en entreprise, commencer avec un compte professionnel est le choix standard, en pensant à la gestion future.⁴

Vous franchissez la frontière au moment où vous voulez que le flux s’exécute sans qu’une personne appuie sur un bouton. Lancer un flux de bureau à une heure fixe ou sur un événement nécessite de le configurer pour être appelé depuis un flux cloud, ce qui demande la préparation suivante.¹⁴

1. Enregistrement de la machine : enregistrez le PC qui exécutera le flux auprès du cloud Power Automate. Se connecter avec l’application d’exécution de machine incluse dans la version MSI l’enregistre. Notez que les éditions Windows 10/11 Home ne prennent pas en charge cette connexion directe.¹⁰
2. Connexion de flux de bureau : créez une connexion (identifiants d’un compte Windows) qui permet au flux cloud de se connecter à cette machine.¹⁴
3. Licence : l’utilisateur qui crée la connexion doit détenir une licence adaptée au mode d’exécution.¹⁴ L’exécuter sur un PC où une personne est connectée — l’exécution assistée — nécessite Power Automate Premium (une licence utilisateur qui inclut les droits RPA assistés).¹⁰⁶
4. L’exécution sans surveillance nécessite en plus l’attribution d’une licence Power Automate Process à la machine. Une licence Process s’attache à la machine (ou au flux), pas à un utilisateur, et vous procure un emplacement d’exécution sans surveillance (un bot sans surveillance) par machine. Point de vigilance : la machine à laquelle vous attribuez une licence Process doit déjà avoir été enregistrée par un utilisateur détenant une licence Premium. Autrement dit, acheter uniquement une licence Process ne permettra rien de configurer s’il n’y a pas d’utilisateur Premium.⁵⁶

Pour résumer : une exploitation où « la personne en charge appuie sur le bouton le matin et observe la saisie se dérouler devant elle » reste entièrement dans le cadre gratuit. Une exploitation où « c’est simplement terminé tout seul au milieu de la nuit » nécessite Premium plus Process (et une machine enregistrée). Si la saisie de données prend environ 30 minutes par jour, il est amplement suffisant de commencer avec l’exécution assistée gratuite et d’envisager le passage au sans surveillance seulement une fois le volume en hausse. Le panorama complet des licences Power Automate — y compris où se situe la frontière entre connecteurs standard et premium — est un sujet qui mérite d’être traité séparément.

6. Concevoir pour un fonctionnement stable

Attendre l’élément, pas un délai fixe

Les anciens systèmes centraux ont des temps de réponse de recherche et d’enregistrement qui varient fortement selon la charge. Un flux réglé avec un Wait fixe du type « attendre 3 secondes » finira forcément par se casser un jour où le système est lent. L’approche de base consiste à utiliser l’action Wait for window content pour « attendre qu’un élément d’interface ou un texte spécifique apparaisse (ou disparaisse) ».⁸ Obtenir une fenêtre (Get window) permet aussi de définir un délai d’expiration, en choisissant entre « échouer après N secondes si non trouvé » ou « attendre indéfiniment qu’il apparaisse ».⁸ Attendre que le message de fin d’enregistrement apparaisse avant de passer à la ligne suivante est particulièrement important dans un flux de saisie de données. Si vous démarrez la saisie suivante sans attendre, l’écran change avant que l’enregistrement de la ligne précédente ne soit terminé, et les données se mélangent.

Construire la gestion des erreurs enregistrement par enregistrement

La pratique standard pour la gestion des erreurs dans un flux de saisie de données consiste à envelopper le traitement d’un seul enregistrement, à l’intérieur de la boucle, dans un bloc On Block Error, plutôt que d’envelopper le flux entier. Lorsqu’une erreur survient, enregistrez ce qui a échoué pour cette ligne, remettez l’écran dans son état initial (fermer l’écran de saisie et revenir au menu, etc.), et passez à la ligne suivante. Ainsi, même si 1 enregistrement sur 100 a un code produit erroné, les 99 autres terminent leur saisie, et seul celui qui a échoué reste à traiter par une personne. Vous pouvez aussi combiner cela avec des paramètres de nouvelle tentative par action pour les erreurs transitoires, comme des réponses lentes.⁹ Pour les points plus fins de la gestion des erreurs — récupérer l’erreur avec Get last error, concevoir l’étape de nettoyage, etc. — voir le guide général et « Gestion des erreurs et conception des tentatives dans Power Automate ».

Permettre de savoir « jusqu’où c’est allé » même en cas d’échec

L’automatisation de l’interface utilisateur n’a pas de transactions comme un système web. Si un flux meurt en cours de route et que vous ne pouvez pas déterminer « quelles lignes sont déjà enregistrées dans le système central », il ne vous reste que deux options : relancer et provoquer des doubles saisies, ou vérifier manuellement chaque enregistrement un par un. Deux conceptions permettent d’éviter cela.

1. Donner au fichier Excel source une colonne de statut. Préparez une colonne de statut avec des valeurs comme « non traité », « en cours », « terminé » et « erreur », plus une colonne pour le numéro d’enregistrement émis par le système central. Passez une ligne à « en cours » avant de commencer sa saisie, confirmez à l’écran que l’enregistrement est terminé et lisez le numéro d’enregistrement, puis réécrivez « terminé » ainsi que le numéro d’enregistrement. Comme le flux ne cible jamais que les lignes encore marquées « non traité », il ne touche jamais aux lignes déjà saisies, quel que soit le nombre de fois où vous le relancez (sûr en cas de relance).
2. Seules les lignes restées bloquées à « en cours » nécessitent une vérification humaine. Si un flux doit mourir, il meurt en pleine saisie, donc les seules lignes suspectes sont celles marquées « en cours ». Il suffit de vérifier le système central pour cette seule ligne avant de relancer, ce qui réduit le périmètre de vérification croisée de 100 enregistrements à un seul.

Cette colonne de statut fait aussi office d’historique d’exécution. Savoir si « la transcription d’hier est bien terminée » peut se répondre en ouvrant Excel, sans même consulter l’historique d’exécution du flux — une forme facile à expliquer sur le terrain.

Les pièges de l’environnement sans surveillance

Nous recevons un nombre réellement élevé de consultations concernant des flux qui fonctionnaient bien en exécution assistée mais qui ont cessé de fonctionner dès le passage en mode sans surveillance. La cause est presque toujours une différence d’environnement.

• Prérequis de session : pour l’exécution sans surveillance, Power Automate crée une nouvelle session de bureau à distance (RDP) sur la machine cible et se déconnecte une fois l’exécution terminée. Pendant qu’elle s’exécute, l’écran de la machine cible reste verrouillé. Comme prérequis, tous les utilisateurs de la machine doivent déjà être déconnectés — sous Windows 10/11, si la session de quelqu’un subsiste (même verrouillée), l’exécution échoue. Sous Windows Server, une erreur survient si une session verrouillée du même utilisateur que la connexion subsiste. Si votre habitude après une opération de maintenance est de vous absenter en « verrouillant » ou en vous « déconnectant » du bureau à distance plutôt qu’en vous déconnectant réellement, le flux nocturne s’arrêtera. Toujours se déconnecter est le mot d’ordre.⁵
• Autorisations : l’utilisateur utilisé pour la connexion doit pouvoir créer une session RDP sur cette machine (généralement en appartenant au groupe Remote Desktop Users). De plus, l’exécution sans surveillance ne prend pas en charge les opérations impliquant une élévation vers les privilèges administrateur.⁵
• Résolution d’écran : la résolution par défaut d’une session RDP peut différer de l’écran sur lequel le flux a été construit. Si la résolution est plus basse, des éléments d’interface visibles lors de la construction du flux se retrouvent cachés hors écran, provoquant des échecs de type « élément introuvable », ou une opération basée sur des coordonnées finit par cliquer ailleurs.⁵ En contre-mesure, vous pouvez fixer la « résolution d’écran pour les exécutions sans surveillance » dans les propriétés du flux à la même valeur que celle utilisée lors de la construction.¹⁵ Les différences de mise à l’échelle DPI provoquent le même type d’échec, il est donc plus sûr de la maintenir à 100 % à la fois lors de la construction et lors de l’exécution.¹⁶

Une fois tout cela vérifié, configurez le déclencheur planifié (par exemple, une exécution chaque matin de jour ouvré à 6 h) du côté du flux cloud. Nous traitons la conception de la planification incluant la vérification des jours ouvrés et le traitement de fin de mois dans « Concevoir des flux planifiés et la logique des jours ouvrés dans Power Automate ».

7. Un exemple de conception pour un flux de saisie de données

En combinant les éléments vus jusqu’ici, voici à quoi ressemble un flux de saisie de données typique conçu comme « fichier Excel de liste de commandes → écran de saisie de commande du système central → réécriture du résultat dans Excel ».

flowchart TD
    Start([Début : manuel ou déclenché depuis un flux cloud]) --> ReadX[Read from Excel worksheet<br/>Lire la liste de commandes, première ligne comme noms de colonnes]
    ReadX --> Filter{Y a-t-il des lignes avec le statut non traité ?}
    Filter -- Non --> Report[Totaliser les résultats et journaliser/notifier] --> End([Fin])
    Filter -- Oui --> Launch[Lancer le système central et se connecter<br/>Confirmer l'affichage de l'écran de menu en attendant l'élément]
    Launch --> Loop[Boucler sur les lignes non traitées une par une<br/>Envelopper le corps de boucle dans On Block Error]
    Loop --> Mark[Mettre à jour la colonne de statut à en cours]
    Mark --> Entry[Ouvrir l'écran de saisie de commande et remplir les champs<br/>Wait for window content à chaque transition d'écran]
    Entry --> Confirm[Bouton d'enregistrement → attendre le message de confirmation<br/>Lire le numéro d'enregistrement émis à l'écran]
    Confirm --> WriteBack[Passer la colonne de statut à terminé et réécrire le numéro d'enregistrement]
    WriteBack --> Loop
    Loop -. Une erreur survient sur un enregistrement .-> Handler[Enregistrer le détail de l'erreur sur cette ligne<br/>Échec avant enregistrement devient erreur / échec après enregistrement reste en cours<br/>Ramener l'écran au menu et passer à la ligne suivante]
    Handler --> Loop
    Loop -- Tous les enregistrements traités --> Close[Se déconnecter du système central et le fermer] --> Report

Quelques remarques sur la conception.

• Valider les valeurs saisies avant toute opération d’interface. Nombre de chiffres du code produit, présence de texte dans un champ numérique, champs obligatoires manquants — validez cela côté flux juste après la lecture d’Excel, et marquez comme « erreur » toute ligne qui semble anormale avant qu’elle ne touche jamais le système central. Rejeter les données incorrectes en amont est bien plus stable que d’essayer de gérer les boîtes de dialogue d’erreur du système central par des opérations d’interface.
• Seul un échec survenant avant que le bouton d’enregistrement ne soit pressé peut être marqué « erreur ». Si votre gestion des erreurs réécrit uniformément la colonne de statut en « erreur », vous marquerez aussi comme « erreur » une ligne qui a échoué après que l’opération du bouton d’enregistrement a déjà réussi (par exemple, pendant l’attente du message de confirmation ou pendant la réécriture), ce qui crée un risque d’accident où le personnel relance cette ligne et elle se retrouve enregistrée deux fois dans le système central. Pour les échecs survenant après l’opération d’enregistrement, laissez la colonne de statut à « en cours » ; ne ciblez jamais pour une relance les lignes restées à « en cours », et faites plutôt vérifier par une personne, en croisant avec le système central, si l’enregistrement a réellement eu lieu, avant de la repasser manuellement à « terminé » ou à « non traité ». Le but de cette conception n’est pas d’éliminer l’ambiguïté : c’est de renvoyer délibérément les cas ambigus à une confirmation humaine, plutôt que de deviner.
• Anticiper les boîtes de dialogue d’erreur à l’écran. Des erreurs de saisie (stock insuffisant, erreur de solvabilité d’un client, etc.) surviennent malgré tout. Capturez toute boîte de dialogue prévisible avec un branchement conditionnel « la fenêtre existe-t-elle », enregistrez-la comme détail d’erreur de cette ligne, et laissez tout ce qui est imprévu à On Block Error.⁹
• Garder une idée approximative du volume et du temps. Il n’est pas rare que l’automatisation de l’interface utilisateur prenne plusieurs dizaines de secondes par enregistrement. Si 100 enregistrements prennent une heure, cela tient largement dans une exécution nocturne sans surveillance, mais s’il y a plusieurs milliers d’enregistrements chaque jour, c’est un signe qu’il faut reconsidérer l’automatisation de l’interface utilisateur elle-même comme méthode (chapitre suivant).
• Terminer la normalisation des données sources en amont. Les pièges venant du CSV/Excel — variations d’encodage des caractères, formats de date incohérents, mélange de caractères pleine chasse et demi-chasse — sont couverts dans « Le CSV n’est pas « juste du texte » : guide pratique du traitement CSV dans les applications métier C# ».

8. Jusqu’où aller avec PAD ?

L’automatisation de l’interface utilisateur finit par se casser, dès que l’écran change. Ce n’est pas quelque chose que la conception peut corriger — c’est le destin de la méthode elle-même. C’est précisément pour cela qu’il faut avoir une ligne claire entre « la saisie de données qu’il est acceptable d’automatiser avec PAD » et « la saisie de données qui devrait évoluer vers le développement ou la modification ».

Comme règle empirique pour cette décision, j’utilise la question suivante : « si ce flux restait cassé pendant une semaine, l’activité continuerait-elle de fonctionner en revenant à la saisie manuelle ? » Si la réponse est oui, l’automatisation avec PAD a largement de la valeur. Si la réponse est non, cette transcription n’est plus une exigence d’« automatisation » — c’est une exigence d’« intégration système », et il est temps d’envisager l’ajout d’une fonction d’importation, une intégration en base de données, ou même la numérisation du traitement des commandes lui-même (voir « Qu’est-ce que l’EDI ? Comment il fluidifie les commandes interentreprises — du fax, de l’e-mail et de la saisie manuelle à l’intégration de données » ou « Faire migrer les commandes par FAX vers le web — concevoir la période de double fonctionnement et une migration par étapes »).

Encore un point : les flux PAD eux-mêmes ont aussi tendance à devenir des « actifs que seule la personne qui les a construits peut toucher ». Qui reprend le contenu du flux, ses connexions et la machine sur laquelle il s’exécute est une question de gouvernance qui mérite d’être conçue délibérément dès le départ, plutôt que d’être traitée après coup.

9. Conclusion

La transcription vers un système central sans API ni importation CSV peut être automatisée « sans toucher au système lui-même » grâce à l’automatisation de l’interface utilisateur de PAD. Sur Windows 11, vous pouvez commencer à l’utiliser directement, et le construire et l’exécuter vous-même ne coûte rien de plus. Le simple fait de libérer le personnel d’une heure de saisie de données quotidienne, et d’éliminer l’investigation et la correction des erreurs de transcription, suffit largement à rentabiliser l’effort d’adoption.

L’important, cependant, c’est de ne pas se tromper dans l’ordre et dans la conception. Cherchez une importation CSV, une base de données, une API ou une intégration par fichier avant de recourir à l’automatisation de l’interface utilisateur. Commencez par l’exécution assistée gratuite, et comprenez les prérequis pour passer au sans surveillance : licences Premium plus Process, et une machine déconnectée. Stabilisez avec les sélecteurs, l’attente des éléments et la gestion des erreurs enregistrement par enregistrement, et préservez toujours « jusqu’où c’est allé » en réécrivant la colonne de statut. Et une fois que le volume, la criticité ou la fréquence des changements d’écran dépasse ce que l’automatisation de l’interface utilisateur peut gérer, ne forcez pas sa croissance : basculez vers la modification du système central ou le développement d’une intégration de données.

Nous prenons en charge tout le continuum, des revues de conception de l’automatisation de la saisie de données avec PAD jusqu’au développement sous contrat de fonctions d’importation et d’intégration inter-systèmes, en passant par la migration d’applications héritées. N’hésitez pas à nous contacter, même au stade du « est-ce que cela peut fonctionner avec notre système central ? ».

Articles connexes

• Automatiser les processus métier avec Power Automate — Flux cloud, flux de bureau et gestion robuste des erreurs
• Combien de temps les applications VB6 vont-elles encore fonctionner ? — État du support d’exécution et un chemin pratique vers la migration vers .NET
• Quand ne pas migrer une application Windows vers le web : un tableau de décision et la réponse pratique de la scission
• Gestion des erreurs et conception des tentatives dans Power Automate
• Le CSV n’est pas « juste du texte » : guide pratique du traitement CSV dans les applications métier C#

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge tout, depuis le conseil sur la conception et la stabilisation de l’automatisation de la saisie de données avec Power Automate for desktop, jusqu’au développement d’intégration de données et à la modification d’applications héritées pour les systèmes centraux qui dépassent ce que l’automatisation de l’interface utilisateur peut gérer.

• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Power Automate for desktop est-il gratuit ?

Oui. L'application Power Automate est intégrée en standard à Windows 11, et elle peut aussi être installée gratuitement depuis le centre de téléchargement de Microsoft sur Windows 10. Les comptes professionnels ou scolaires disposent, sans coût supplémentaire, de tout l'ensemble des fonctions de création de flux et d'exécution manuelle (assistée) : l'enregistreur, plus de 400 actions, la gestion des erreurs. En revanche, le lancement automatique depuis un flux cloud, le partage de flux et la gestion centralisée des journaux d'exécution nécessitent tous une licence payante Power Automate Premium.

Que faut-il pour exécuter un flux de saisie de données la nuit ou tôt le matin, sans personne présent ?

L'exécution sans surveillance (unattended) nécessite une configuration où un flux cloud l'appelle, ce qui suppose au préalable l'enregistrement de la machine cible, la création d'une connexion de flux de bureau, et l'attribution d'une licence Power Automate Process à la machine. L'enregistrement de la machine lui-même doit également être effectué par un utilisateur détenant une licence Premium. Sur le plan technique, l'exécution sans surveillance fonctionne en créant une nouvelle session de bureau à distance, ce qui impose que tous les utilisateurs de la machine cible soient déjà déconnectés : s'il reste ne serait-ce qu'une seule session verrouillée, l'exécution échoue sous Windows 10/11.

On dit que l'automatisation de l'interface utilisateur est fragile. Est-ce vraiment utilisable en pratique ?

Elle est utilisable en pratique tant que les écrans du système central ciblé restent stables. La plupart des causes de casse tiennent à la façon dont les éléments d'interface sont identifiés (les sélecteurs) et à un manque d'attente, si bien que la stabilité s'améliore considérablement avec des choix de conception comme remplacer les attributs dont la valeur change par des correspondances Contains ou des expressions régulières, mettre en place des sélecteurs de secours, ou attendre l'apparition d'un élément plutôt que d'utiliser un délai fixe. Cela dit, la fatalité de finir par se casser lorsque la mise en page de l'écran change ne disparaît jamais complètement : si l'application cible est mise à jour fréquemment, ou si le volume ou l'importance du travail rend une interruption inacceptable, il vaut mieux envisager le développement d'une intégration de données ou la modification du système central lui-même plutôt que l'automatisation de l'interface utilisateur.

Si un flux de saisie de données échoue en cours de route, ne risque-t-on pas de perdre la trace de ce qui a déjà été saisi ?

Cela peut être évité avec une conception adaptée. Le point clé est de donner au fichier Excel source une colonne de statut (non traité / en cours / terminé / erreur) et une colonne de numéro d'enregistrement, puis de vérifier le résultat de l'enregistrement côté système central et de réécrire le statut après chaque enregistrement. Ainsi, en cas d'échec, le fichier Excel conserve exactement les lignes déjà enregistrées, et relancer le flux ne cible plus jamais que les lignes encore marquées « non traité », ce qui évite toute double saisie. Gérer les erreurs enregistrement par enregistrement — en journalisant la ligne en échec puis en passant à la suivante — évite aussi qu'une seule erreur de saisie n'arrête tout le traitement.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.