Aller au contenu

Migration depuis un RPA commercial

Depuis UiPath Depuis AA Depuis Blue Prism Depuis TagUI Portée fixe

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.

On obtient un accès lecture à votre bibliothèque de scripts actuelle. On catalogue :

  • Scripts au total, par type (process automation, tests UI, RPA, etc.)
  • Patterns les plus utilisés (sélecteurs, image, OCR, appels API)
  • Intégrations externes (bases de données, APIs, systèmes de fichiers, schedulers)
  • Appels OS natifs (Windows COM, scripting macOS, shell Linux)
  • Infrastructure CI / scheduling existante
  • Workflow de l’équipe ops (qui édite, qui exécute, qui supervise)

Livrable : un rapport d’audit écrit avec catégorisation, scoring de complexité par script et proposition de stratégie de migration.

Sur la base de l’audit, on propose :

  • Quels scripts migrent directement (la logique visuelle se traduit proprement)
  • Quels scripts nécessitent une réécriture (sélecteur-lourds, APIs spécifiques vendeur)
  • Quels scripts devraient être abandonnés plutôt que migrés (souvent plus que vous ne le pensez — les stacks RPA accumulent du cruft)
  • Un batch pilote pour valider l’approche (typiquement 5-15 scripts représentant les patterns principaux)

C’est vous qui décidez ce qui avance. La stratégie est collaborative.

On migre le batch pilote de bout en bout :

  • Convertir les scripts en OculiX
  • Installer OculiX dans votre environnement de test
  • 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)

Section intitulée « Phase 4 — Déploiement (2 à 6 semaines selon la taille de la bibliothèque) »

On migre les scripts restants par lots, en validant chaque lot avant de continuer. Votre équipe est impliquée pour :

  • Valider les scripts convertis contre les critères d’acceptation
  • Faire tourner les scripts convertis en production en parallèle de l’original (shadow mode) sur une durée définie
  • Décider quand basculer chaque lot

Livrable : bibliothèque complète tournant sur OculiX en production, plateforme RPA d’origine encore chaude pour rollback.

On déroule un handover structuré :

  • Session de formation pour l’équipe ops (exécution, scheduling, debug, monitoring)
  • Documentation de l’architecture du nouveau stack, incluant l’intégration CI / scheduling
  • Runbook pour les scénarios opérationnels courants (un script échoue, une image doit être re-capturée, un nouveau layout casse un pattern)
  • Support post-handover sur 30 jours inclus, pour gérer les inévitables surprises terrain

Livrable : équipe autonome faisant tourner OculiX en production, documentation complète, filet de sécurité borné dans le temps.

✅ Se traduit bien

  • Cliquer sur un bouton identifié par apparence (icône, label, couleur)
  • Saisir du texte dans un champ localisé visuellement
  • Attendre qu’un écran apparaisse
  • Capturer et OCR-iser une zone de l’écran
  • Gestes drag-and-drop UI
  • Opérations système de fichiers
  • Exécution de commandes shell
  • Boucles, conditionnelles, gestion d’erreurs

⚠️ Nécessite une réécriture

  • Sélecteurs basés sur DOM / XPath / hooks accessibilité (pas d’équivalent exact ; on utilise des ancres visuelles)
  • Connecteurs spécifiques vendeur (Salesforce, SAP) — remplacés par appels API ou workflows visuels
  • Logique d’éditeur de workflow visuel — aplatie en scripts linéaires
  • Appels COM natifs (patterns Windows-only) — ré-exprimés en flux visuel quand faisable
  • Intégration Robot Framework (on a un support natif mais les tests nécessitent migration)

Groupe d'assurance français

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.

Tous nos scripts marcheront-ils après migration ?

Section intitulée « Tous nos scripts marcheront-ils après migration ? »

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) ?

Section intitulée « 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) ?

Section intitulée « 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 ?

Section intitulée « 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.

🦎