Les équipes sous plateforme RPA commerciale (UiPath, Automation Anywhere, Blue Prism) ou OSS à l’arrêt (TagUI, Sakuli) qui veulent migrer vers OculiX n’ont pas à tout réinventer. Un engagement de migration cadre le projet, fixe un livrable, et le livre selon un calendrier écrit.
On ne fait pas de prosélytisme, mais voici ce qu’on entend des équipes qui ont sauté le pas :
Prévisibilité des coûts
Les frais par bot et par runtime peuvent grimper à six ou sept chiffres annuels au volume entreprise. OculiX a zéro frais de licence pour toujours (MIT). La conversation TCO devient « infra + personnes » au lieu de « infra + personnes + licence ».
Pas de vendor lock-in
Avec un RPA commercial, si votre éditeur monte les prix, retire une fonctionnalité, se fait racheter, ou s’effondre (cf. l’arrêt de TagUI par AI Singapore), vos bots sont coincés. MIT, source-available, auto-hébergé signifie que vous maîtrisez le calendrier de chaque changement.
Parité multi-plateforme
OculiX tourne à l’identique sur Windows, macOS, Linux depuis un JAR unique par plateforme. UiPath Studio est Windows-only. AA / Blue Prism ont des contraintes similaires. Les équipes à infra mixte arrêtent de maintenir des workflows parallèles.
Scriptabilité réelle
Les scripts OculiX sont du vrai Python (Jython) ou du Java. Versionnables dans git, diffables, code-reviewables, testables avec les frameworks standards. L’éditeur de workflow visuel des RPA commerciaux est pratique en faible volume, pénible en gros volume.
Couche visuelle pure
OculiX travaille sur ce qui est à l’écran, pas sur les sélecteurs / DOM / hooks d’accessibilité. Les apps qui changent leur structure interne en gardant leur layout visuel ne cassent pas OculiX. Le RPA basé sur les sélecteurs UI casse à chaque release.
Pas de télémétrie
OculiX n’envoie rien à l’extérieur. Rien ne sort de votre réseau. Pour les secteurs régulés (banque, défense, santé, gouvernement), c’est souvent le facteur décisif — même une revue d’architecture du cloud du vendeur n’aide pas, puisqu’il n’y a pas de cloud à revoir.
Exécuter les scripts convertis contre vos fixtures de test
Comparer la sortie aux exécutions originales du RPA commercial (rapport de delta)
Corriger les écarts
Documenter les patterns appris
Livrable : scripts pilote tournant dans votre environnement, sortie identique à l’original, plus un récap écrit « leçons apprises » qui informe la suite de la migration.
Phase 4 — Déploiement (2 à 6 semaines selon la taille de la bibliothèque)
150 scripts RPA sur UiPath, mix d’onboarding client et de traitement documentaire. Migration sur 8 semaines. Résultat : coût de licence passé de 280 k€/an à 0 €, infra grossièrement identique, scripts post-nettoyage tombés à 110 (40 étaient obsolètes et personne ne l’avait remarqué).
Chaîne retail APAC
40 scripts TagUI (après l’arrêt par AI Singapore), besoin d’une alternative maintenue. Migration sur 3 semaines puisque TagUI se traduit proprement en OculiX (modèle visuel similaire). Résultat : mêmes workflows, runtime supporté, pas de licence.
Provider healthcare US
60 scripts Automation Anywhere dans un déploiement Windows-only, voulant s’étendre à un back-office Linux. Migration sur 6 semaines vers OculiX. Résultat : mêmes scripts tournant sur les deux OS, consolidation d’infra, audit trail (module MCP) branché pour les preuves HIPAA.
Industrie allemande
Mix Blue Prism et Selenium custom pour l’automation au sol. Migration sur 5 semaines du sous-ensemble Blue Prism vers OculiX. Selenium conservé pour les flows web spécifiques. Résultat : séparation propre entre automation visuelle (OculiX) et web (Selenium), chaque outil dans son domaine de prédilection.
L’audit Phase 1 vous dit par écrit ce qui marche directement, ce qui nécessite réécriture, ce qui devrait être déprécié. On ne promet pas que « tout se traduit comme par magie » — ça, c’est du marketing. On promet que « chaque script a un état de destination documenté avant qu’on y touche ».
Et nos jobs planifiés (cron / Task Scheduler / orchestrateur RPA) ?
Les scripts OculiX tournent comme des process Java standards. Ils s’intègrent avec n’importe quel scheduler — cron, Task Scheduler Windows, GitHub Actions, Jenkins, Airflow, votre orchestrateur RPA existant (oui, vous pouvez faire tourner des scripts OculiX DEPUIS un Run Shell d’un orchestrateur en période de transition).
Les scripts OculiX tournent en headless via le mode -r script.py en CI. On a intégré avec Jenkins, GitHub Actions, GitLab CI, Azure Pipelines, TeamCity. Le handover Phase 5 inclut le câblage de votre CI spécifique.
Session dédiée Phase 5 (typiquement 1 jour on-site ou 2 demi-journées remote). Inclut : exécution manuelle de scripts, debug en cas d’échec, capture de nouvelles ancres image quand une UI change, monitoring des runs production, flow d’escalade. Sessions enregistrées livrées dans le runbook.
Fixé par portée, pas par heure. L’audit Phase 1 est le livrable qui nous permet de coter le reste avec confiance. Des engagements audit-only sont aussi possibles (évaluation de 1-2 semaines avec rapport écrit et estimation de migration) si vous voulez cadrer avant de vous engager sur le projet complet.
Peut-on rouler en shadow mode (ancien et nouveau en parallèle) ?
Oui, et c’est l’approche recommandée pour la Phase 4. La plateforme RPA d’origine reste chaude, les scripts convertis tournent en parallèle, la sortie est comparée, vous décidez quand basculer par lot. On a supporté des périodes shadow de 1 semaine à 3 mois.
Vous possédez tout le code migré. La plateforme RPA d’origine n’est jamais touchée. Le rollback c’est abandonner les nouveaux scripts et garder l’ancienne plateforme vivante. Le travail effectué reste à vous, pas de lock-in contractuel.
Couvrez-vous la migration VERS OculiX depuis Selenium / Cypress ?
Pas en offre standard — ce sont des outils de test web avec une portée différente. OculiX complète plutôt qu’il ne remplace (automation visuelle aux côtés du test DOM). Les conversations d’architecture sur leur combinaison font partie de l’engagement Revue d’architecture.
Demander un engagement audit-onlyAssessment cadré sur 1-2 semaines avec rapport écrit et estimation de migration. Vous permet de décider sur le projet complet avec des données réelles.
Demander un cadrage de migration complèteDécrivez votre plateforme actuelle, le nombre approximatif de scripts et le calendrier souhaité. On revient avec une proposition par phases.