Le screen scraping passe vite pour un retour en arrière. Ce n'est justifié que lorsqu'un système n'a pas d'interface. Quand cela s'applique et quand non.
Le screen scraping a mauvaise réputation, et le plus souvent à juste titre. Lorsqu'un robot logiciel clique à travers des masques d'écran au lieu de récupérer les données via une interface, c'est rarement la solution propre. Il existe pourtant, dans les PME, des processus où c'est justement la seule voie possible. La question décisive n'est pas de savoir si la méthode paraît dépassée, mais si le système cible dispose d'une interface exploitable.
Le screen scraping désigne la lecture et la manipulation automatisées d'une application via son interface écran : un robot déplace le curseur de la souris, remplit des champs et lit des valeurs sur le masque, exactement comme le ferait un humain. Une intégration API contourne l'interface et communique directement avec l'interface de données du système.
Microsoft résume la différence dans sa documentation Power Automate en une formule concise : avec une API, on dit à l'application ce qu'elle doit faire, avec l'interface, on le lui montre (Types d'automatisation des processus, Microsoft Learn). Une seule de ces deux approches constitue un engagement. Une interface est une promesse de l'éditeur que les champs et les formats resteront identiques. Un masque d'écran n'est pas cette promesse.
La recommandation est sans ambiguïté, et elle vient des éditeurs RPA eux-mêmes. Microsoft conseille de choisir l'automatisation basée sur API pour toute application disposant d'un connecteur API, car les interfaces sont censées rester stables même lorsque l'application évolue.
Selon l'éditeur, Power Automate couvre plus de 380 applications avec des connecteurs API prêts à l'emploi, auxquels s'ajoutent des connecteurs personnalisés pour tout système doté d'une API disponible (Microsoft Learn). L'automatisation via l'interface n'est donc pas une alternative équivalente à l'intégration API, mais la sortie de secours documentée. Qui se tourne d'abord vers le robot achète une charge de maintenance que personne n'a commandée.
Le prix à payer est la charge de maintenance, et elle est bien documentée. Les automatisations via l'interface dépendent de sélecteurs, c'est-à-dire de la description technique de l'emplacement et du nom d'un élément d'interface. Si cette description change, le robot ne trouve plus l'élément et l'exécution échoue.
Pour les flux de bureau exécutés sans surveillance, Microsoft recense six facteurs pouvant rendre un sélecteur inutilisable : la résolution d'écran et la mise à l'échelle DPI, les mises à jour de l'application, la version du système d'exploitation, la taille de la fenêtre, l'état d'un élément et les autorisations de l'utilisateur connecté (Dépannage de l'exécution sans surveillance, Microsoft Learn). Aucun de ces points n'a de lien avec le processus métier. Le processus reste tout aussi correct, c'est l'automatisation qui trébuche sur l'emballage.
UiPath décrit le même problème sous un autre angle : les sélecteurs classiques s'appuient sur des attributs et des hiérarchies rigides, ce qui fait qu'une étiquette modifiée, un identifiant d'élément dynamique ou un nouveau thème suffisent à arrêter l'automatisation. L'éditeur évalue lui-même cette charge de maintenance comme élevée (À propos des sélecteurs sémantiques, UiPath Docs). Avec une intégration API, aucun de ces problèmes n'existe. Une interface ne se soucie pas de la résolution d'écran.
Le screen scraping est le bon moyen lorsqu'un système ne dispose d'aucune interface exploitable et ne peut être piloté que via son interface écran. Microsoft précise la condition dans sa documentation de licence : la RPA est nécessaire pour les applications pour lesquelles il n'existe ni connecteur prêt à l'emploi ni API permettant d'en construire un.
En pratique, cela concerne cinq situations :
Ce dernier point est régulièrement négligé : l'approche est une technologie de transition légitime. Elle ne devient un problème que lorsque le pont devient un état permanent et que plus personne ne sait pourquoi il est là. Nous avons traité la question de l'outil lui-même dans notre comparatif pratique entre n8n et Power Automate.
Il faut alors aussi intégrer dans le calcul les coûts de licence qui disparaissent avec la variante API. Avec Power Automate, chaque machine exécutant des flux de bureau sans surveillance nécessite une licence Process, et pour Microsoft 365 une licence Unattended supplémentaire (Microsoft Learn). Du point de vue des licences, le robot est un utilisateur supplémentaire. Nous avons détaillé les briques de licence UiPath dans notre article sur les licences UiPath pour les PME.
Avant toute décision RPA, il convient de faire une vérification qui prend généralement une demi-heure et rend régulièrement le robot superflu. Il existe souvent une interface, elle porte simplement un autre nom. Quatre questions permettent d'y voir clair :
Si la décision se porte quand même sur le robot, la justification doit être consignée par écrit. Pour une administration communale, nous avons présenté exactement cette analyse en juillet 2026 et déconseillé de faire de la RPA le fondement de la stratégie d'automatisation : oui comme complément ponctuel, non comme base. L'outil n'était pas mauvais, il ne correspondait simplement pas à la tâche. Cette analyse est le véritable contenu d'un accompagnement en conseil interfaces et intégration.
Le web scraping lit le contenu de pages web, généralement via le code source HTML, et ne nécessite pour cela aucune interface visible. Le screen scraping pilote l'application telle qu'un humain la voit, et englobe les programmes de bureau ainsi que les sessions terminal et Citrix.
Techniquement oui, contractuellement cela dépend. Certains éditeurs de logiciels excluent l'utilisation automatisée dans leurs conditions d'utilisation ou la conditionnent à des licences supplémentaires. Avant de construire un robot, il convient de vérifier les conditions de licence du système cible, avec un avis juridique en cas de doute.
Non, mais le risque ne peut pas être éliminé par la programmation. Une mise à jour qui ne change que la logique métier laisse le robot intact. Dès que les libellés, la structure des fenêtres ou les identifiants d'éléments changent, les sélecteurs ne trouvent plus rien. Qui utilise la RPA doit donc intégrer la maintenance comme un élément prévu, et non la traiter comme un incident.
Ils l'atténuent, ils ne l'éliminent pas. Des éditeurs comme UiPath travaillent sur des sélecteurs qui reconnaissent un élément par sa signification plutôt que par sa position. Cela réduit la charge de maintenance, mais ne change rien au fait que l'automatisation dépend d'une interface que personne ne garantit contractuellement stable.
Fondateur de NordFlux. Sept ans d'expérience, du web et du SEO jusqu'à l'automatisation à l'échelle d'un groupe, aujourd'hui pragmatique pour les PME et avec une souveraineté des données allemande.
Certifications
Automatiser SAP via Citrix : pourquoi les sélecteurs UiPath échouent dans les sessions virtuelles et quelles approches restent réellement stables en pratique.
SAP mentionne lui-même les bots RPA dans le Digital Access. Ce que cela signifie pour le RPA sur SAP et Business One, et quand la propre pile de SAP est la voie la plus courte.
Studio, Robots, Orchestrator, Platform Units : ce dont une PME a vraiment besoin chez UiPath, ce que cela coûte et quand un autre outil revient moins cher.
Le screen scraping semble être la seule option en l'absence d'interface, mais c'est rarement la solution la moins coûteuse. Nous examinons votre paysage applicatif à la recherche d'API disponibles et, uniquement là où aucune interface n'existe réellement, nous construisons une solution RPA robuste qui résiste à la prochaine mise à jour.
