Les outils RPA open source à retenir et où les exécuter

Plusieurs outils d'une sélection classique de RPA open source ne peuvent pas fonctionner sur un serveur Linux sans environnement graphique. Ils automatisent des interfaces de bureau et dépendent d'une session graphique, alors qu'un serveur nu n'en possède aucune à contrôler. Cette seule caractéristique divise la catégorie en deux et détermine où votre robot peut fonctionner.

Les licences RPA commerciales motivent la plupart des recherches des meilleurs outils RPA open source. J'ai vérifié à nouveau les licences, l'activité et les paquets ci-dessous le 5 octobre 2026. Chaque affirmation sur leur statut renvoie au document qui la justifie.

Points clés

• Commencez par les besoins de session, pas par la liste des fonctions. Oculix, OpenRPA et taskt privilégient les interfaces graphiques et nécessitent une session graphique pour travailler sur un bureau local. RPA Framework n'en a pas besoin pour les navigateurs, fichiers et données. Pour TagUI et UI.Vision, cela dépend du mode utilisé.
• RPA Framework a publié des versions en février, mars, mai, juin, août et octobre 2026. C'est l'historique de publication le plus régulier vérifié ici.
• TagUI est sous Apache-2.0 et accepte encore les contributions, mais AI Singapore a arrêté sa maintenance et son assistance. Son wrapper Python n'a connu aucune publication depuis juillet 2023.
• Automagica et OpenBots ne devraient pas figurer dans une sélection actuelle. Automagica a cessé d'être sous AGPL3 lorsque Netcall a acquis l'entreprise en octobre 2020, et OpenBots n'a aucun dépôt public maintenu pour un produit RPA.
• Si les systèmes que vous reliez proposent déjà des API ou des webhooks, il vous faut une automatisation de workflows, pas de la RPA. Autre catégorie, autres outils, développement bien plus court.

Ce que cet article n'aborde pas

Trois questions voisines sont exclues, chacune pour une raison différente.

• Les plateformes commerciales avec une offre gratuite. UiPath Community Edition et l'offre gratuite de Power Automate relèvent d'une décision distincte de celle traitée ici.
• L'installation et la configuration. Rien de ce qui suit n'est un guide d'installation, et aucun outil n'est accompagné de commandes à exécuter.
• Les agents IA qui utilisent un ordinateur. Un outil de la liste propose une intégration de ce type : nous lui consacrons une phrase, pas une comparaison.

Les outils RPA open source encore maintenus

Les six projets ci-dessous répondent au critère retenu : de vrais logiciels RPA open source avec une activité publique depuis mi-2025. Les outils RPA gratuits dont la maintenance a cessé restent gratuits ; la colonne qui mérite le plus d'attention est donc celle des dates, pas celle des licences. Les autres précisent ce que chaque outil automatise et ce qu'il exige de sa machine.

rpaframework est une collection de bibliothèques, pas une application. Vous écrivez du Python ou du Robot Framework et importez les composants nécessaires. Le démarrage est plus exigeant que l'enregistrement d'une macro, mais la maintenance est beaucoup plus simple. Son dépôt le présente comme optimisé pour Control Room, le produit commercial d'orchestration que Robocorp a construit autour de lui. Un membre de Sema4.ai dans une discussion sur r/rpa décrit Robocorp comme faisant désormais partie de Sema4.ai et énonce clairement la séparation. La bibliothèque est sous Apache-2.0, la plateforme ne l'est pas. Le propriétaire a changé, la séparation est restée. Le Robot Framework sous-jacent est lui aussi sous Apache-2.0 et ne constitue pas un autre outil à ajouter à la sélection.

L'extension de navigateur de UI.Vision est son cœur open source. L'automatisation du bureau nécessite un téléchargement distinct, une application locale appelée XModules, qui fournit à l'extension la reconnaissance d'images et de texte afin de cliquer hors du navigateur. La licence est double (AGPLv3 ou accord commercial). Si vous modifiez le cœur open source et ne souhaitez pas respecter les obligations de partage du code d'AGPLv3, la licence commerciale est l'autre option.

taskt est le cas délicat. Sa branche de développement a reçu un commit en juillet 2025, mais sa dernière version étiquetée, v3.5.0.0, remonte à mai 2020. Commits et publications sont des indicateurs différents. Une longue période sans nouvelle version ne signifie pas que la version existante a cessé de fonctionner.

SikuliX mérite une précision : son nom désigne désormais essentiellement la lignée historique. Son dépôt amont d'origine a été archivé en mars 2026 et le miroir oculix-org dirige les utilisateurs actuels vers Oculix, sa continuation active sous MIT. C'est donc Oculix qu'il faut retenir aujourd'hui ; SikuliX1 apporte surtout un contexte historique et de compatibilité, plutôt qu'une entrée maintenue.

Deux noms apparaissent encore dans les sélections alors qu'ils ne devraient pas y figurer. Le README d'Automagica annonce l'acquisition de l'entreprise par Netcall le 13 octobre 2020 et indique que le robot n'est plus disponible sous AGPL3. Quant à l'organisation GitHub publique d'OpenBots, elle contient un dépôt de sites statiques et une bibliothèque d'émulation de terminal, mais aucun cœur RPA.

Interface graphique ou mode sans affichage : ce qui détermine votre serveur

Un outil RPA open source nécessite une session graphique si le workflow automatise une interface de bureau. L'automatisation des API, fichiers et données peut fonctionner sans affichage, tout comme celle du navigateur si celui-ci est lancé en mode headless. Les outils de reconnaissance d'images ont en plus besoin de pixels à examiner. Cependant, une automatisation du bureau peut dépendre d'une session graphique même lorsqu'elle identifie les contrôles avec des sélecteurs plutôt qu'avec des images.

Une session de bureau est l'environnement graphique ouvert après connexion : un écran, un gestionnaire de fenêtres et un pointeur avec des coordonnées. Le mode headless désigne l'inverse : une machine fonctionnant sans écran attaché. La plupart des serveurs Linux loués sont livrés ainsi par défaut.

Cette distinction découle des dépendances de l'automatisation. Oculix, comme SikuliX avant lui, utilise la vision par ordinateur pour trouver un bouton en comparant une image enregistrée aux pixels affichés. Il lui faut donc une surface graphique à examiner. Un navigateur piloté par une API d'automatisation peut fonctionner sans affichage de bureau. L'automatisation du bureau par sélecteurs est encore différente : elle reconnaît des contrôles plutôt que des pixels, mais peut néanmoins exiger un environnement graphique. Pour la RPA open source sur serveur, la question pratique est donc de savoir si le workflow nécessite une session graphique.

TagUI et UI.Vision sont à cheval sur les deux catégories, selon le mode utilisé. La documentation de référence de TagUI précise que son option -headless lance un workflow dans un navigateur Chrome invisible et ne fonctionne pas pour l'automatisation visuelle. UI.Vision automatise le navigateur dans une extension et le bureau via XModules. Celui-ci reconnaît des images à l'écran et exige donc un écran sur lequel les reconnaître.

Un affichage virtuel comble une partie de l'écart. Xvfb permet de fournir à un serveur Linux headless un affichage en mémoire où des programmes graphiques dessinent sans spectateur. Cela rend possible une automatisation visuelle sans moniteur. Il ne fera pas fonctionner un outil réservé à Windows sur Linux et ajoute une couche supplémentaire à maintenir en état à trois heures du matin.

Une licence et une date de commit vous indiquent si un outil sera encore là l'année prochaine. Les besoins de session vous disent si vous pouvez réellement l'exécuter.

Où chaque outil fonctionne

Un robot qui agit sur l'écran nécessite une session graphique qu'il peut contrôler, qu'il s'agisse d'un bureau réel, d'une session distante ou d'un affichage virtuel. Un robot headless n'en a pas besoin. Les deux paraissent évidents jusqu'au moment où le robot doit démarrer à 3 h sans personne devant le clavier.

La RPA auto-hébergée impose une exigence opérationnelle quel que soit l'outil : la machine doit être dans le bon état lorsque la tâche planifiée démarre. Sous Windows, cet état est précis, et Microsoft le décrit pour son propre produit. Sa documentation des flux de bureau sans surveillance de Power Automate indique que le produit crée une session de bureau distant sur la machine cible, que les exécutions sans surveillance ne peuvent pas utiliser la session console et qu'une machine Windows 10 ou Windows 11 ne peut pas exécuter le flux si une session utilisateur est présente, même verrouillée. Sous Windows Server, une session verrouillée ouverte avec le même utilisateur que la connexion provoque une erreur.

C'est l'implémentation d'un fournisseur, pas une règle universelle de Windows. Elle illustre toutefois les défaillances possibles, car tout robot agissant sur l'écran doit résoudre le même problème : disposer d'une session interactive. Votre propre session ouverte est souvent l'obstacle. Sous Linux, le problème équivalent est plus limité, mais existe : une tâche qui continue après la fermeture de votre session SSH nécessite un planificateur et un gestionnaire de services, pas un terminal laissé ouvert.

Windows Server gère les sessions différemment des éditions de bureau. Son rôle RD Session Host exécute des bureaux basés sur des sessions sur une seule machine pour permettre plusieurs sessions. Une session de robot et la vôtre peuvent donc coexister. Pour cette utilisation de RD Session Host, chaque utilisateur ou appareil qui se connecte nécessite une RDS CAL. C'est un coût à prévoir dès le début, pas à découvrir à la fin.

Le dimensionnement reste modeste. Je ne prévoirais pas plus de 1 vCPU et 2 Go de RAM pour un robot qui parcourt un formulaire en cliquant et écrit un fichier. Pour un navigateur complet, je prévoirais 2 vCPU et au moins 4 Go, surtout avec plusieurs onglets : Chrome est la partie coûteuse du travail, bien plus que l'outil d'automatisation qui le pilote.

Une vieille machine dans un placard peut suffire. Elle doit rester allumée, conserver sa session ouverte et ne pas être le portable que vous fermez le soir. Un serveur loué évite cette catégorie de problèmes : il fonctionne indépendamment du portable et ne partage pas la session de bureau sur laquelle vous travaillez.

Si louer une machine vous convient mieux que l'entretenir, cette distinction correspond à deux produits. Un Windows VPS avec une image Desktop ou Server fournit à un robot visuel un environnement Windows dédié ; un Linux VPS couvre les workflows sans affichage. Tous deux fonctionnent que votre portable soit ouvert ou non.

Quel outil choisir

Si le travail se passe dans un navigateur ou dans des fichiers et que vous savez écrire du Python, RPA Framework est le choix à retenir ; le reste concerne les cas particuliers. La réponse change dès qu'une application de bureau sans API intervient : il faut alors un outil capable d'interagir avec un bureau graphique, et la sélection devient plus courte et plus ancienne.

Pour les navigateurs, fichiers et données sur un serveur Linux, choisissez RPA Framework. Il fonctionne sans affichage, s'installe sur une machine sans écran sans dispositif supplémentaire et a publié une version en octobre 2026. En échange, vous écrivez du Python ou du Robot Framework plutôt que d'enregistrer une macro. Cela coûte au démarrage, mais facilite chaque adaptation de l'application cible.

Pour une application Windows ancienne sans API, si vous voulez une automatisation visuelle plutôt qu'un développement complet, choisissez UI.Vision, avec une réserve. Il reçoit des commits cette année, contrairement à certaines options de bureau. La partie AGPLv3 de sa double licence entraîne des obligations de partage du code source si vous modifiez et distribuez le logiciel open source. taskt vient en second : sa branche de développement reste active, mais sa dernière version étiquetée date de mai 2020. Il faut peser cet écart entre recevoir des commits et publier des versions.

Pour automatiser visuellement ce qui apparaît à l'écran sur plusieurs plateformes, choisissez Oculix, la continuation active de SikuliX. Il privilégie toujours les images plutôt que les sélecteurs, mais propose désormais un IDE et des versions actives, au-delà des simples primitives de comparaison d'images. Utilisez-le lorsque la cible est constituée de pixels plutôt que d'un DOM ou d'un arbre d'accessibilité. Considérez le dépôt archivé SikuliX1 comme la lignée historique plutôt que le produit maintenu.

TagUI reste recommandé pour une raison : son langage ressemble à l'anglais courant et son apprentissage est le plus facile des six. Son README indique en revanche que AI Singapore a arrêté la maintenance et l'assistance, tandis que les contributeurs open source et la communauté poursuivent le projet. Ce n'est pas un abandon : des corrections arrivent encore sur la branche par défaut et le dépôt n'est pas archivé. Ce n'est pas non plus une forte dynamique ; le wrapper Python rpa sur PyPI a plusieurs années de retard sur le journal des commits. Choisissez TagUI pour une tâche que vous pouvez figer, pas pour une plateforme à développer pendant trois ans.

OpenRPA est plus difficile à juger. Il propose de véritables fonctions d'orchestration sous MPL-2.0, mais son dernier commit de code et sa dernière version étiquetée datent tous deux de juin 2025, et la seule activité du dépôt depuis lors se limite à des branches automatisées de mise à jour des dépendances. Il ne s'agit pas d'un abandon, puisque rien n'est archivé, mais rien n'a été publié non plus. Pesez cet écart selon la durée pendant laquelle vos robots devront fonctionner.

Quand un outil RPA dédié n'est pas la bonne réponse

L'argument le plus solide contre tout ce qui précède vient de quelqu'un qui fait ce travail. Dans une discussion sur r/selfhosted lancée par un opérateur voulant sortir d'un contrat RPA commercial, une réponse recommande plutôt Python et un framework d'automatisation comme Selenium. Plus d'efforts au développement, moins de pannes ensuite, et un coût de possession inférieur à celui du logiciel RPA utilisé par ce commentateur. Un autre participant de la même discussion approuve indépendamment.

Le critère décisif est la maintenance. Si la tâche doit durer des années, si le volume est élevé et si vous ou quelqu'un de votre équipe pouvez maintenir une petite base de code, écrivez le code. Selenium et Playwright coûtent davantage le premier jour et moins le quatre-centième, car un script que vous avez écrit échoue de façons que vous pouvez comprendre. Si la tâche a un horizon de quelques mois, ou si personne dans l'équipe ne code, le chemin plus court de l'outil RPA vers un robot fonctionnel vaut sa fragilité.

Le résultat d'un enregistreur vieillit le plus mal. Un script généré à partir de vos clics dépend de la disposition enregistrée. Une page redessinée ou un bouton déplacé le casse donc d'une manière que le message d'erreur explique rarement. Certains sont encore plus sceptiques envers cette catégorie : dans une discussion sur r/rpa consacrée aux options open source, un commentateur décrit la RPA comme du scripting reconditionné vendu à des responsables non techniques. Pour une tâche suffisamment limitée, cette description n'est pas injuste.

Il faut aussi éviter une erreur de catégorie. Si les systèmes reliés exposent des API ou des webhooks, vous n'avez pas besoin de RPA. La RPA pilote l'interface lorsqu'aucun autre accès n'existe ; l'automatisation de workflows utilise directement cet accès, ce qui réduit le développement et la fragilité. Les outils et leurs coûts sont différents ; la licence de n8n et son coût d'auto-hébergement sont la première question à régler. n8n, Node-RED, Apache Airflow, Kestra et Dagu sont disponibles en un clic sur notre marketplace si vous souhaitez en lancer un aujourd'hui.

Le site actuel de UI.Vision annonce une intégration d'Anthropic Computer Use. La catégorie intègre donc déjà des agents qui pilotent un écran en raisonnant sur ce qu'ils voient plutôt qu'en comparant des images enregistrées.

Foire aux questions