Screen Scraping ou API : quand la RPA est-elle vraiment encore nécessaire

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.

Qu'est-ce que le screen scraping et en quoi diffère-t-il d'une intégration API ?

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.

API ou screen scraping : ce que recommandent les éditeurs eux-mêmes

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.

Pourquoi le screen scraping devient plus coûteux en maintenance

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.

Quand le screen scraping est-il vraiment le bon choix ?

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 :

• Anciennes applications métier sans API : des logiciels métier historiques qui n'ont jamais été conçus pour l'intégration.
• Applications terminal et Citrix : lorsque seule une image d'écran arrive, il n'y a techniquement rien d'autre à saisir que le masque.
• L'interface est verrouillée : certains éditeurs concèdent le module API séparément ou ne le mettent pas du tout à disposition des petits clients. La question devient alors commerciale, et non technique.
• L'API ne couvre pas le processus : une interface qui ne fait que lire n'aide pas pour l'opération d'écriture nécessaire.
• La période de transition avant un remplacement : si le système doit être remplacé dans un an ou deux, une intégration propre n'est souvent plus rentable. Un robot construit délibérément comme solution jetable devient alors l'investissement le plus honnête.

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.

Comment vérifier qu'il n'existe vraiment aucune interface ?

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 :

• Que dit la documentation de l'éditeur ? les modules API apparaissent souvent dans la documentation technique bien avant de figurer dans l'offre commerciale.
• Existe-t-il un export de données ? l'interface la plus discrète est un export CSV ou XML planifié. Il est stable, documenté et ne coûte rien.
• Un accès en lecture à la base de données est-il possible ? pour les analyses, cela suffit souvent amplement.
• Combien coûte le module d'interface ? à titre unique, il est souvent moins cher que trois ans de maintenance du robot.

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.

Questions fréquentes

Quelle est la différence entre screen scraping et web scraping ?

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.

Le screen scraping est-il autorisé ?

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.

Le screen scraping cesse-t-il vraiment de fonctionner à chaque mise à jour ?

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.

Les sélecteurs pilotés par l'IA résolvent-ils le problème ?

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.