AstronRPA : une suite RPA auto-hébergée pilotée par agents, à réserver à Windows
Agent-ready RPA suite with out-of-the-box automation tools. Built for individuals and enterprises.
En bref
- De quoi s’agit-il ?
- La suite RPA open source d'iFlytek combine un designer visuel low-code, un moteur Python 3.13 et une intégration native à la plateforme Astron Agent. Le déploiement serveur passe par Docker Compose, mais le client reste lié à Windows 10/11 et le build à une chaîne d'outils lourde.
- À qui s’adresse-t-il ?
- AstronRPA convient aux équipes déjà sur Windows et qui veulent garder le contrôle de leurs données d'automatisation, en particulier si elles utilisent déjà Astron Agent. À éviter si votre parc est majoritairement Linux ou macOS, ou si vous ne pouvez pas assumer une chaîne de build Node 22, Python 3.13, JDK 8, pnpm, UV, 7-Zip et SWIG.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 5 jours.
- En quel langage est-il écrit ?
- Principalement Java, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : automatiser le poste de travail, pas seulement le navigateur
La plupart des outils d'automatisation open source se limitent au web. AstronRPA vise explicitement les applications de bureau Windows et les pages web dans un même flux. Le README cite WPS et Office, des logiciels de gestion comme Kingdee et YonYou, ainsi que IE, Edge et Chrome. C'est le cas d'usage classique de la RPA d'entreprise : un processus qui commence dans un ERP, passe par un tableur, puis se termine dans un portail web.
Le projet ne s'adresse donc pas à un développeur qui veut scripter une API. Il s'adresse à une équipe qui doit faire dialoguer des logiciels fermés, sans accès à leur code source. La documentation mentionne un designer visuel avec glisser-déposer, ce qui déplace la création de processus vers des profils métier plutôt que vers des développeurs. Le dépôt annonce plus de 300 composants atomiques couvrant les opérations d'interface, le traitement de données et les interactions système. Ce chiffre vient du README, pas d'un inventaire que j'aurais pu vérifier.
Un point mérite attention : la cible principale annoncée est Windows 10/11. Toute équipe dont le parc est majoritairement Linux ou macOS est hors du périmètre fonctionnel du client, même si le serveur, lui, se déploie sous Docker.
Deux binaires qui ne vivent pas au même endroit
L'architecture se lit dans le guide de démarrage rapide : un serveur déployé avec Docker Compose, et un client installé sur chaque poste. Le serveur expose plusieurs ports, dont 32742 pour l'API RPA et 8000 pour Casdoor, le service d'authentification. Le client, lui, est une application de bureau construite à partir d'un moteur Python et d'une interface web.
La configuration du client tient dans un fichier YAML, resources/conf.yaml, placé dans le répertoire d'installation. Deux clés y sont documentées : remote_addr, qui pointe vers le serveur, et skip_engine_start, un booléen qui contrôle le démarrage du moteur local. Ce découpage signifie que le poste de travail exécute réellement les automatisations, tandis que le serveur gère l'orchestration, l'authentification et probablement le partage de composants. Le README évoque un centre d'excellence, une place de marché d'équipe, la surveillance des terminaux et des modes de planification.
L'intégration avec Astron Agent est présentée comme bidirectionnelle : appel de nœuds de workflow RPA depuis un agent, et usage de workflows d'agent dans AstronRPA. Le README mentionne aussi MCP parmi les canaux de déclenchement, aux côtés de l'exécution directe, des tâches planifiées et des appels API. Autrement dit, un agent peut déclencher un processus RPA comme n'importe quel autre outil exposé via MCP. C'est cohérent avec la description du dépôt, qui parle de suite RPA prête pour les agents.
Mise en route : Docker côté serveur, build.bat côté poste
Le déploiement serveur tient en quelques commandes, telles que le README les donne. On clone le dépôt, on entre dans docker, on copie .env.example vers .env, puis on renseigne CASDOOR_EXTERNAL_ENDPOINT avec l'adresse du serveur et le port 8000. Ensuite, docker compose up -d, puis docker compose ps pour vérifier l'état des services.
La vérification proposée est inhabituelle mais pratique. On ouvre http://{IP}:32742/api/rpa-auth/user/login-check et l'on doit obtenir un message d'erreur JSON contenant code 900001 et message unauthorized. Ce résultat négatif est en fait le signe que la chaîne d'authentification répond. Le README indique ensuite d'ouvrir le port 8000 pour voir la page de connexion Casdoor.
Côté client, deux voies existent : télécharger un paquet de release, ou construire depuis les sources. Le script build.bat accepte un argument --python-exe pointant vers un interpréteur Python 3.13. Le README précise que cet interpréteur doit être une installation propre, sans paquets tiers, afin de limiter la taille du paquet. Le build enchaîne six étapes : copie de l'environnement Python vers build/python_core, installation des dépendances du moteur, compression en resources/python_core.7z, installation des dépendances frontend, build de l'application web, puis build de l'application de bureau. La réussite est signalée par le message Full Build Complete!.
Les dépendances déclarées sont nombreuses : Node.js 22 ou plus, Python 3.13.x, JDK 8 ou plus, pnpm 9 ou plus, UV 0.8 ou plus, 7-Zip et SWIG. Cette dernière sert à relier Python au C/C++. Une machine de build vierge demandera donc une préparation réelle avant la première compilation.
Ce que la documentation ne tranche pas
Le README s'arrête au mot Architect, tronqué. Les détails d'architecture interne, la façon dont les composants sont stockés, la manière dont les workflows sont versionnés ou exécutés en parallèle ne sont pas dans le matériel fourni. Je ne peux donc pas décrire le modèle d'exécution du moteur Python au-delà de ce que le guide de build laisse voir.
Plus gênant pour une décision d'adoption : le durcissement en production est renvoyé à docker/QUICK_START.md, que je n'ai pas. Le README mentionne lui-même un guide de déploiement pour la production et la sécurité, ce qui suggère que la configuration par défaut n'est pas prévue pour une exposition directe. Le fait que la vérification de bon fonctionnement consiste à obtenir un message unauthorized va dans ce sens : l'authentification est active dès le départ, mais rien n'indique quels réglages changer avant d'ouvrir le service sur un réseau d'entreprise.
Autre zone d'ombre : la licence Apache-2.0 couvre le code du dépôt. Elle ne dit rien des modules d'entreprise mentionnés dans le README, ni des composants tiers que le client embarque. Pour un déploiement interne, cela n'a probablement pas d'incidence. Pour une redistribution, il faudrait vérifier fichier par fichier, notamment du côté du moteur Python et des bibliothèques d'automatisation d'interface.
La contrainte Windows et le coût de maintenance
Le client est annoncé pour Windows 10/11 en support principal. Ce n'est pas un détail d'implémentation, c'est une frontière. Une organisation qui gère un parc hétérogène devra maintenir une flotte Windows dédiée aux robots, ou renoncer. Les serveurs, eux, peuvent tourner sous Linux via Docker, ce qui limite la casse mais ne supprime pas le besoin de machines Windows pour l'exécution.
Le build depuis les sources impose une seconde contrainte. Une chaîne Node 22, Python 3.13, JDK 8, pnpm, UV, 7-Zip et SWIG doit être reproduite sur chaque poste de compilation, et le README insiste sur un Python propre. Cela signifie qu'un environnement Python partagé avec d'autres outils produira un paquet plus lourd que nécessaire, voire des conflits de dépendances. Le projet fournit un paquet de release, ce qui est la voie raisonnable pour la plupart des équipes.
Sur les mises à jour, le rythme observé dans les releases est irrégulier : v1.1.5 fin janvier 2026, v1.1.6 fin février 2026, et une préversion nightly v1.1.2-nightly en décembre 2025. Le dépôt n'est pas archivé et le dernier push est daté de septembre 2026. Ces dates montrent une activité, pas une politique de support. Rien dans le matériel ne précise combien de temps une version est maintenue, ni s'il existe des branches de correctifs. Une équipe qui déploie sur des centaines de postes doit obtenir cette information avant de standardiser.
Face à un orchestrateur de navigateur comme Playwright
L'alternative la plus directe pour l'automatisation web est Playwright, ou Selenium pour les cas plus anciens. La différence d'approche est nette. Playwright pilote un navigateur par son protocole de débogage, avec un modèle d'attente intégré et une API en code. Il ne sait pas cliquer dans une application Windows native, ne fournit pas de designer visuel, et ne gère ni file d'exécution ni authentification centralisée.
AstronRPA prend le problème par l'autre bout : un serveur d'orchestration, un client lourd, des composants visuels et une exécution sur le poste. Le prix à payer est une infrastructure plus lourde et une dépendance à Windows. L'avantage est la couverture des logiciels sans API, ce que Playwright ne fera jamais.
Le choix dépend donc de la nature du processus. Si tout passe par un navigateur et que l'équipe sait écrire du code, Playwright reste plus simple à versionner et à exécuter dans un pipeline d'intégration continue. Si le processus traverse un ERP client lourd, un tableur et un portail web, l'approche d'AstronRPA est la seule des deux qui tienne. Il n'y a pas de recouvrement réel entre les deux outils, et c'est probablement la conclusion la plus utile de cette comparaison.
Pour qui, et quoi vérifier avant d'installer
Le projet vise deux publics que le README distingue mal. D'un côté des individus qui veulent automatiser des tâches sur leur poste, avec un designer visuel et un serveur Docker local. De l'autre des entreprises qui ont besoin de contrôle des permissions, de partage d'équipe et de conformité, avec des thématiques comme data-privacy, security-compliance et on-premise affichées dans le dépôt.
Le second public est celui pour qui l'auto-hébergement change quelque chose : les données d'automatisation, les identifiants et les captures d'écran restent sur l'infrastructure de l'organisation. C'est l'argument principal face aux offres SaaS de RPA, et il tient à condition que le durcissement soit fait. Le premier public peut se contenter du paquet de release et d'un docker compose up -d.
Trois vérifications concrètes avant d'aller plus loin. Premièrement, ouvrir docker/QUICK_START.md et lire ce que le projet recommande de changer par rapport au .env.example. Deuxièmement, confirmer que le script build.bat accepte votre installation Python 3.13 sans paquets tiers, car c'est une condition écrite noir sur blanc dans le README. Troisièmement, tester l'appel via MCP depuis Astron Agent si c'est l'usage visé, puisque le README présente cette intégration comme le principal différenciateur du projet.
Conclusion éditoriale
AstronRPA convient aux équipes déjà sur Windows et qui veulent garder le contrôle de leurs données d'automatisation, en particulier si elles utilisent déjà Astron Agent. À éviter si votre parc est majoritairement Linux ou macOS, ou si vous ne pouvez pas assumer une chaîne de build Node 22, Python 3.13, JDK 8, pnpm, UV, 7-Zip et SWIG. Avant de vous engager, vérifiez deux points dans le dépôt : le contenu réel de docker/QUICK_START.md pour le durcissement en production, et la compatibilité de votre version de Python avec le script build.bat.
Notes de la communauté