Automatiser un logiciel métier sans API : construire un robot RPA de bout en bout

Le projet en 30 secondes

1. Tout est parti d'une tâche que je n'avais plus envie de faire

Ce projet n'était pas prévu.

Il est né pendant une période relativement calme où plusieurs de mes sujets étaient en attente et où j'avais terminé ce que j'avais à faire.

Plutôt que de simplement attendre, j'ai commencé à regarder les tâches répétitives autour de moi.

Et une en particulier m'agaçait.

Les extractions de l'ERP.

À ce moment-là, j'avais déjà construit plusieurs outils qui dépendaient de ces données.

Une partie de mes reportings utilisait des exports ERP.

Mon pipeline Data en avait besoin pour actualiser sa base historique.

Mon système d'automatisation de KPI avait besoin d'une extraction contenant les dossiers à analyser.

Le problème était que tout ce qui se passait après l'extraction devenait progressivement automatisé…

…mais quelqu'un devait toujours aller chercher les données au début.

Et ce quelqu'un, c'était souvent moi.

Il fallait ouvrir le logiciel.

Naviguer jusqu'à la fonction recherchée.

Renseigner les paramètres nécessaires.

Lancer l'extraction.

Exporter le résultat en CSV.

Puis recommencer avec la suivante.

Rien de particulièrement difficile.

Mais toujours les mêmes actions.

Toujours dans le même ordre.

Avec pratiquement toujours les mêmes paramètres.

Je me suis donc posé une question assez évidente :

si je fais exactement les mêmes clics toutes les semaines, pourquoi est-ce encore moi qui les fais ?

2. Première idée : utiliser une API

Lorsque je cherche à automatiser un système, mon premier réflexe n'est normalement pas de construire un robot qui clique sur des boutons.

Si deux systèmes peuvent communiquer directement, c'est généralement préférable.

J'ai donc commencé par regarder s'il existait une manière plus propre de piloter l'ERP:

API, connexion directe et Accès aux données.

Une interface permettant de demander automatiquement :

« Exécute cette requête avec ces paramètres et renvoie-moi le résultat. »

Dans mon contexte, aucune de ces solutions n'était réellement exploitable.

L'ERP était un logiciel métier ancien, très fermé et accessible dans un environnement particulier.

Il existait bien différentes possibilités autour du système, mais pas une API que je pouvais simplement utiliser pour construire mon automatisation.

J'avais donc deux possibilités.

Continuer à faire les extractions manuellement ou trouver une autre manière de communiquer avec le logiciel.

Et c'est là que l'idée du RPA est apparue.

Si je ne peux pas parler directement au logiciel, je peux peut-être apprendre à un robot à l'utiliser comme moi.

3. Première version : apprendre au robot où cliquer

Je suis parti de la méthode la plus intuitive.

Observer exactement ce que je faisais.

Avec Codex, j'ai commencé à documenter le parcours.

Capture d'écran après capture d'écran.

Position de la souris.

Fenêtres ouvertes.

Menus utilisés.

Boutons.

Champs.

Séquence des actions.

L'objectif était de partir du lancement de l'environnement et d'aller jusqu'au fichier CSV final.

À partir de ces observations, nous avons commencé à construire des scripts capables de reproduire les actions.

Le principe était très simple:

Si je savais que le bouton se trouvait à un endroit donné de l'écran, le script pouvait déplacer le curseur à cet endroit et cliquer.

Puis attendre.

Puis cliquer ailleurs.

Puis remplir un champ.

Et ainsi de suite.

Après plusieurs essais et corrections, le robot a commencé à réussir le parcours.

Il lançait l'application.

Naviguait.

Arrivait au bon endroit.

Exécutait la requête.

Et produisait son CSV.

À ce moment-là, j'étais plutôt satisfait.

Ça marchait.

J'avais automatisé mon extraction.

Du moins, je le pensais.

4. Jusqu'au lendemain

Le lendemain, j'ai voulu refaire un test dans une configuration différente.

Cette fois, je n'étais plus exactement dans le même environnement d'affichage.

Nombre d'écrans différent.

Résolution différente.

Disposition différente.

Je lance le robot.

Et il clique à côté.

Puis encore à côté.

Le problème est devenu évident très rapidement.

Mon robot ne savait absolument pas ce qu'était le bouton sur lequel je voulais qu'il clique.

Il savait uniquement :

« À cette étape, clique à cet endroit de l'écran. »

Par exemple :

X = 742 / Y = 416

Mais si la résolution change, ce point ne correspond plus forcément au même élément.

Si la fenêtre bouge, même problème.

Si l'application n'est pas positionnée exactement comme prévu, même problème.

J'avais construit quelque chose qui reproduisait mes mouvements.

Je n'avais pas construit quelque chose qui comprenait réellement sur quoi agir.

C'était embêtant.

Mais c'est aussi ce problème qui a rendu le projet beaucoup plus intéressant.

5. Mon premier robot ne voyait que des pixels

Quand un humain regarde une interface, il ne réfléchit pas en coordonnées.

Je ne me dis pas :

« Je dois cliquer à 742 pixels du bord gauche. »

Je vois :

« Export CSV ».

Si je change d'écran et que le bouton se déplace légèrement, je continue à savoir ce que c'est.

Le robot, lui, n'avait aucune idée de ce qu'il regardait.

Il ne connaissait ni les boutons, ni les menus, ni les champs.

Il connaissait seulement l'écran.

C'était donc ça qu'il fallait changer.

Je ne voulais plus lui apprendre :

où cliquer.

Je voulais essayer de lui apprendre :

sur quoi cliquer.

6. Arrêter de regarder l'écran et commencer à regarder l'application

J'ai commencé à creuser davantage.

Si cette application fonctionne sous Windows, le système doit nécessairement connaître certaines informations sur les fenêtres et les éléments qui composent son interface.

J'ai donc exploré les informations que Windows était capable d'exposer sur l'interface :

les fenêtres, les contrôles, certains éléments identifiables, leur organisation et leurs propriétés accessibles.

Avec Codex, nous avons ensuite construit différents outils de diagnostic permettant de comprendre quels composants de l'interface pouvaient être identifiés et utilisés de manière fiable par l'automatisation.

Et progressivement, l'écran que je voyais comme utilisateur a commencé à avoir une deuxième lecture.

D'un côté :

l'interface graphique.

De l'autre :

la structure technique de cette interface.

Cette exploration a été beaucoup plus longue que de simplement enregistrer quelques coordonnées.

Il fallait comprendre ce qui était réellement accessible.

Tester.

Identifier le mauvais contrôle.

Revenir en arrière.

Comparer.

Réessayer.

Mais une fois les bons éléments identifiés, le projet changeait complètement de niveau.

7. Passer du Pixel Automation au UI Automation

La première version raisonnait ainsi :

« Clique à cet endroit. »

La nouvelle approche pouvait raisonner davantage ainsi :

« Identifie le contrôle correspondant à l'action recherchée et interagis avec lui. »

Pour construire cette deuxième version, j'ai utilisé des scripts PowerShell s'appuyant notamment sur les capacités d'automatisation de l'interface disponibles dans l'environnement Windows/.NET.

Le robot pouvait maintenant interagir beaucoup plus directement avec certains composants.

La résolution de l'écran devenait moins critique.

La position exacte de la fenêtre également.

Et surtout, je n'avais plus besoin de laisser ma souris effectuer visiblement chaque mouvement du processus.

Le logiciel pouvait travailler dans son environnement pendant que je continuais à faire autre chose.

C'était exactement ce que je cherchais.

Je ne voulais pas simplement créer une macro impressionnante à regarder.

Je voulais ne plus avoir à m'occuper de l'extraction.

8. Apprendre au robot le processus complet

Identifier un bouton ne suffit évidemment pas à automatiser un ERP.

Il fallait reconstruire toute la séquence.

Le robot devait savoir comment démarrer.

Attendre que le logiciel soit prêt.

Naviguer jusqu'à la fonction attendue.

Renseigner les paramètres nécessaires.

Lancer le traitement.

Attendre et contrôler le résultat.

Déclencher l'export.

Puis vérifier que le fichier avait réellement été créé.

À ce stade, une distinction importante est apparue.

Un robot capable de cliquer n'est pas forcément un robot fiable.

9. Le vrai problème n'est pas de faire une action. C'est de savoir si elle a réussi.

Prenons une séquence très simple :

ouvrir une requête ;

l'exécuter ;

exporter le résultat ;

passer à la suivante.

Si tout se déroule parfaitement, le script fonctionne.

Mais que se passe-t-il si la première requête échoue ?

Si le logiciel met plus de temps que prévu ?

Si le fichier n'est pas créé ?

Si une fenêtre inattendue apparaît ?

Un mauvais robot continue.

Il suppose que tout s'est bien passé.

Il passe à l'étape suivante.

Puis à la suivante.

Et quelques minutes plus tard, il annonce éventuellement qu'il a terminé alors que son premier export n'existe même pas.

Ce n'était pas ce que je voulais construire.

Il fallait donc arrêter de penser uniquement en actions.

Il fallait commencer à penser en :

action → contrôle → décision.

10. Ajouter des garde-fous

Le workflow a progressivement intégré différents contrôles.

Après une extraction, le robot ne devait pas immédiatement supposer que tout était bon.

Il fallait vérifier le résultat attendu.

Le fichier existe-t-il ?

L'étape s'est-elle terminée correctement ?

Le résultat permet-il de continuer ?

Dans la séquence finale, la deuxième extraction n'est notamment lancée que lorsque la première a été explicitement validée.

Cette logique paraît évidente.

Mais elle fait une énorme différence.

Je ne voulais pas seulement automatiser le scénario idéal.

Je voulais que le robot sache s'arrêter lorsqu'il n'était plus certain d'être dans le scénario idéal.

Dans beaucoup d'automatisations, savoir ne pas continuer est presque aussi important que savoir continuer.

11. Si le robot travaille seul, il doit laisser des traces

Un autre problème apparaît lorsqu'une automatisation devient réellement autonome.

Imaginons que le robot tourne un matin alors que personne ne le regarde.

Une heure plus tard, je vois deux CSV dans un dossier.

Très bien.

Mais que s'est-il réellement passé ?

À quelle heure a-t-il démarré ?

Quelle étape a été exécutée ?

A-t-il rencontré une erreur ?

A-t-il recommencé une action ?

Comment savoir pourquoi il s'est arrêté si un fichier manque ?

Il fallait donc ajouter de la traçabilité.

Le système conserve différents éléments permettant de suivre ses exécutions :

• journaux d'exécution ;

• statuts des différentes étapes ;

• rapports structurés ;

• captures de contrôle lorsque nécessaire ;

• informations permettant de comprendre où le processus s'est arrêté.

Des rapports JSON peuvent notamment conserver un état structuré de l'exécution.

Le but n'est pas de créer des logs pour le plaisir.

Le but est très concret :

si quelque chose ne fonctionne pas, je veux savoir où regarder.

12. Faire travailler le robot quand je ne suis pas là

Une fois la séquence suffisamment fiable, il restait une dernière étape assez logique.

Pourquoi lancer le script manuellement ?

Le processus devait être exécuté régulièrement.

J'ai donc intégré son lancement à une tâche planifiée Windows.

À l'heure prévue, le workflow peut démarrer.

Le script lance le processus.

L'ERP est piloté.

Les requêtes sont exécutées.

Les CSV sont générés.

Les contrôles sont effectués.

Les logs sont conservés.

Puis le robot termine.

La tâche que je réalisais auparavant manuellement devenait donc quelque chose qui pouvait se produire en arrière-plan.

Et c'est là que ce petit projet de R&D a commencé à devenir beaucoup plus intéressant.

13. Parce que ces CSV ne sont pas la fin du processus

Si le résultat du projet avait simplement été :

« J'ai automatisé le téléchargement de deux fichiers CSV »

je le trouverais déjà utile.

Mais ce n'est pas ce qui le rend vraiment intéressant.

Ces fichiers sont utilisés ailleurs.

Dans d'autres projets, j'ai construit des pipelines permettant de transformer certaines extractions ERP, de les consolider et d'alimenter différents outils Data et reportings.

Le RPA peut automatiser le tout début de ces chaînes.

C'est là que j'ai commencé à voir le projet différemment.

Je n'avais pas seulement automatisé quelques clics.

J'avais automatisé une partie de l'alimentation de plusieurs autres automatisations.

C'est là que j'ai commencé à voir le projet différemment.

Je n'avais pas seulement automatisé quelques clics.

J'avais automatisé une partie de l'alimentation de plusieurs autres automatisations.

14. Le RPA comme passerelle vers un système legacy

Ce projet m'a aussi fait comprendre pourquoi le RPA reste intéressant alors qu'il existe aujourd'hui énormément d'API et de connecteurs.

Dans un système moderne, je préférerais presque toujours une connexion directe.

Si une API stable permet de demander proprement la donnée :

j'utilise l'API.

Si une base peut être interrogée directement :

je préfère interroger la base.

Si un connecteur fiable existe :

je regarde d'abord le connecteur.

Le RPA n'est pas mon premier choix simplement parce qu'il est spectaculaire de voir un robot utiliser un logiciel.

Mais toutes les entreprises n'utilisent pas uniquement des systèmes modernes.

Des logiciels métiers développés il y a longtemps restent parfois absolument centraux.

Ils fonctionnent.

Les équipes les connaissent.

Les remplacer coûterait énormément.

Mais ils ne communiquent pas facilement avec le reste de l'écosystème.

Dans ce contexte, le RPA peut devenir une passerelle.

Il permet de faire travailler un système ancien avec des processus beaucoup plus modernes sans nécessairement remplacer immédiatement tout le logiciel.

15. Une fois le premier processus automatisé, on commence forcément à regarder les autres

À l'origine, mon besoin concernait principalement mes propres extractions.

Mais une fois le robot fonctionnel, une autre question apparaît naturellement :

quelles autres tâches suivent exactement le même principe ?

Dans un ERP, il y en a souvent beaucoup.

Certaines opérations de facturation.

Certaines créations ou mises à jour de dossiers.

Certaines extractions.

Certaines saisies répétitives.

Évidemment, tout n'est pas automatisable.

Et surtout, tout ne mérite pas de l'être.

Certaines opérations dépendent énormément du client, du contexte ou de décisions humaines.

Construire un robot gigantesque capable de gérer toutes les exceptions peut rapidement devenir beaucoup plus coûteux que le problème initial.

Mais lorsqu'une tâche possède trois caractéristiques :

répétitive ;

stable ;

déterministe ;

elle devient une candidate particulièrement intéressante.

16. Ce que le RPA ne résout pas

Je ne considère pas ce robot comme une solution magique.

Piloter une interface utilisateur reste plus fragile qu'utiliser une API conçue spécifiquement pour permettre à des systèmes de communiquer.

Une mise à jour importante du logiciel peut modifier certains contrôles.

Une nouvelle fenêtre peut apparaître.

Une authentification peut évoluer.

L'ERP peut être indisponible.

L'environnement Windows peut changer.

Un processus RPA nécessite donc du suivi.

C'est précisément pour cela que j'ai ajouté des contrôles, des logs et des arrêts conditionnels.

Le but n'est pas de prétendre que rien ne peut casser.

Le but est plutôt de construire le système de manière à ce que, lorsqu'une situation inattendue arrive :

il ne continue pas aveuglément.

Et surtout :

je puisse comprendre ce qui s'est passé.

17. De quelques clics automatisés à un véritable processus

Avec le recul, l'évolution du projet est assez amusante.

Au départ, mon objectif était simplement :

« Je veux automatiser mes clics. »

J'ai donc appris au robot à reproduire mes mouvements.

Puis la résolution de mon écran a changé.

Et tout a cassé.

Cela m'a obligé à aller beaucoup plus loin.

Comprendre comment Windows voit l'application.

Explorer ses composants.

Identifier les contrôles.

Construire des sondes.

Interagir avec l'interface autrement.

Ajouter des validations.

Ajouter des logs.

Ajouter une orchestration.

Puis planifier l'ensemble.

Finalement, ce projet n'est plus vraiment un projet d'automatisation de souris.

C'est un projet d'automatisation de processus.

Et la différence est importante.

18. Ce que je retiens de ce projet

C'est probablement l'un des projets sur lesquels j'ai le plus appris simplement en essayant quelque chose qui, au départ, paraissait assez basique.

Je voulais supprimer une tâche répétitive.

Ma première solution fonctionnait.

Puis elle a cassé presque immédiatement dans un environnement légèrement différent.

J'aurais pu continuer à ajuster les coordonnées.

Ajouter des conditions selon la résolution.

Repositionner automatiquement les fenêtres.

Créer toujours plus de rustines autour du même principe.

À la place, j'ai essayé de comprendre pourquoi l'approche était fragile.

Et le problème était finalement simple :

j'avais automatisé les gestes d'un humain plutôt que le processus suivi par l'humain.

À partir du moment où le robot a commencé à identifier l'interface, contrôler ses actions et prendre une décision avant de poursuivre, le projet est devenu beaucoup plus robuste.

C'est une logique que je retrouve aujourd'hui dans beaucoup d'automatisations.

Le but n'est pas de reproduire exactement ce que fait une personne.

Le but est de comprendre :

ce qu'elle cherche à accomplir, quelles étapes sont réellement nécessaires et comment vérifier que chacune d'elles a réussi.

19. Pas d'API ne veut pas forcément dire pas d'automatisation

Beaucoup d'entreprises possèdent encore des logiciels métiers anciens.

Ils sont parfois peu agréables à utiliser.

Ils communiquent mal avec les outils modernes.

Ils n'ont pas toujours d'API accessible.

Et pourtant, ils restent absolument indispensables au fonctionnement quotidien.

Cela ne signifie pas automatiquement que toutes les actions réalisées à l'intérieur doivent rester manuelles.

Avant de parler de RPA, je regarderais toujours s'il existe une solution plus directe et plus robuste.

Mais lorsqu'aucune connexion adaptée n'existe, je poserais une question beaucoup plus simple :

est-ce qu'une personne réalise toujours les mêmes actions, dans le même ordre, selon les mêmes règles ?

Si la réponse est oui, il y a probablement quelque chose à étudier.

Parce qu'entre remplacer un ERP entier et continuer à cliquer manuellement pendant dix ans, il existe parfois une troisième possibilité :

apprendre au système à faire lui-même une partie du travail.