Date publication

Apr 29, 2026

Comment utiliser OculiX ?

Cet article est publié sans sponsoring, sans partenariat commercial et sans intérêt financier extérieur. Il s’adresse aux équipes qui évaluent une solution d’automatisation visuelle en 2026 et veulent connaître toutes les options disponibles, y compris celles qui ne paient pas pour apparaître dans les médias spécialisés.

Cet article est rédigé par Julien Mer.

3 - Cas d’usage concrets

Applications packagées métier

OculiX est particulièrement pertinent sur les progiciels customisés de type ERP, CRM, PLM, GED. Le moteur visuel s’adapte aux changements d’identifiants HTML entre versions sans impact sur les scripts. L’OCR lit les libellés métier indépendamment de la police ou de la taille. Les tests de non-régression restent stables au fil des montées de version.

Clients lourds legacy

Sur les applications desktop anciennes pour lesquelles aucune API d’accessibilité n’est exposée, OculiX automatise là où les autres outils ne peuvent pas. Interfaces Win32, applications VB, clients métier développés dans les années 2000 — tout ce qui est visible à l’écran est automatisable.

Tests cross-plateformes

Un parcours métier impliquant une application web, un client lourd et une appli mobile peut être scripté dans un seul fichier Java. OculiX bascule entre Screen local, VNC distant et ADB Android de façon transparente via son abstraction de Region.

Tests de caisses et terminaux retail

Piloter 200 caisses enregistreuses distantes via VNC-over-SSH, lire les montants affichés par OCR, vérifier la cohérence entre l’interface caissier et le ticket imprimé : des cas réels couverts sans outil commercial à cinq chiffres.

Mobile Android en production

Tests de charge sur une flotte de tablettes terrain, tests d’une application mobile métier sur plusieurs versions Android, automatisation de scénarios utilisateur sur appareils physiques connectés en WiFi — directement depuis l’IDE OculiX.

Tests visuels end-to-end entre front et back

Vérification de la cohérence entre une interface front et une base de données, entre un CRM et un ERP, entre un écran utilisateur et un log applicatif — grâce à la capacité de lecture et de comparaison du moteur OCR.

4 - Automatiser les mainframes IBM et les terminaux 5250/3270

Les systèmes mainframe IBM — AS400 (devenu iSeries puis IBM i) et MVS (devenu z/OS) — sont au cœur de pans entiers de l’économie. Cœurs bancaires de production, contrats d’assurance, paies de fonctionnaires, dossiers patients hospitaliers, inventaires industriels, gestion de stocks logistiques : ces infrastructures accumulent quarante à cinquante ans de logique métier et ne disparaîtront pas de sitôt. Les tentatives de migration vers des architectures modernes s’étalent sur des décennies, et le COBOL continue de tourner en production dans la majorité des grandes institutions françaises et européennes.

L’accès à ces systèmes se fait via des émulateurs de terminal qui affichent des écrans verts en mode caractère : le protocole 5250 pour les AS400 et IBM i, le protocole 3270 pour z/OS et MVS. Ces interfaces sont totalement invisibles à Selenium, à Appium, à Cypress et à Playwright. Aucune notion de DOM, aucune API d’accessibilité, aucune automation native exposée. La navigation est clavier-uniquement — touches F1 à F24, Enter, Tab, attributs PA1, PA2, PA3 — et le rendu purement textuel sur fond noir.

OculiX automatise nativement ces terminaux par deux mécanismes complémentaires. D’un côté, l’OCR lit les zones de texte des écrans verts : libellés, codes erreur, montants, statuts de transactions. Tesseract gère bien les polices monospace caractéristiques des émulateurs, et PaddleOCR prend le relais lorsque les écrans deviennent denses ou dégradés par des transmissions réseau anciennes. De l’autre, la reconnaissance d’image identifie les éléments graphiques récurrents de l’émulateur — zones de menu, icônes, indicateurs d’état, bannières — ainsi que les patterns visuels qui structurent les écrans métier.

Combiné au mode VNC, OculiX pilote à distance n’importe quel poste hébergeant un émulateur, qu’il soit déployé en Citrix VDI, en machine virtuelle interne, ou directement sur le poste d’un opérateur. L’émulateur peut être PCOMM (IBM Personal Communications), Mocha TN5250/TN3270, Attachmate Reflection, Wavelink ou n’importe quel client TN5250/TN3270 du marché — OculiX ne s’intéresse qu’à l’écran rendu, jamais au client qui le produit. Un changement d’émulateur au sein de l’entreprise ne casse pas les scripts, ce qui est une rupture nette avec les outils qui parsent les API propriétaires de chaque éditeur de terminal.

Mode headless pour batch et CI/CD mainframe

Les tests batch sur mainframe ont leurs propres contraintes. Vérifier 200 transactions COBOL nocturnes, valider qu’un job batch n’a pas régressé après un changement de PTF, contrôler visuellement qu’un écran de saisie comptable affiche les bons libellés après une mise à jour CICS : ces scénarios se jouent la nuit, sans opérateur humain, et doivent produire un rapport exploitable au matin.

OculiX s’exécute en mode headless sur un serveur Linux dédié qui pilote en VNC les postes Windows hébergeant les émulateurs. Aucune interface graphique n’est requise sur le serveur OculiX lui-même : un display virtuel Xvfb suffit. Le job CI/CD lance le jar, OculiX se connecte aux postes émulateur, exécute la suite de tests, capture les écrans verts pour le rapport et retourne un code de sortie standard. L’approche est compatible sans adaptation avec Jenkins, GitLab CI, GitHub Actions et Azure DevOps.

Cette capacité positionne OculiX dans le cercle très étroit des outils open source capables d’automatiser des infrastructures historiques et modernes dans une même suite de tests. Un parcours métier qui démarre dans une application web React, descend dans un AS400 via un émulateur 5250, valide en base DB2 puis se termine dans un workflow mobile Android devient scriptable de bout en bout dans un seul script Java. Peu d’outils commerciaux savent faire ça. Aucun autre outil open source ne le propose.

5 - OculiX dans l’écosystème Java, Selenium et Grid

Le principe fondamental : une API Java dans la JVM

OculiX est une API Java. Son jar s’ajoute comme dépendance Maven standard dans n’importe quel projet JVM - Java, Kotlin, Scala, Groovy, Clojure - et les classes du package org.sikuli.script deviennent directement appelables, sans pont, sans wrapper, sans chargement dynamique. C’est le mode d’emploi principal, celui recommandé pour construire une suite de tests d’entreprise sur le long terme.

L’écosystème Maven Central est accessible par construction : un projet qui utilise OculiX peut aussi importer Selenium WebDriver, Rest Assured, Apache POI, JDBC, PDFBox, Jackson, Jsoup, WireMock, JUnit ou TestNG — il suffit d’ajouter les dépendances dans le pom.xml et d’importer les classes. Aucune adaptation, aucune couche intermédiaire. L’intégration est structurelle, pas applicative.

En parallèle de ce mode principal, OculiX embarque par héritage de SikuliX un interpréteur Jython — Python 2.7 tournant dans la JVM — qui permet à l’IDE OculiX d’exécuter des scripts .py. Les scripts Jython appellent la même API Java, avec la même logique, en bénéficiant de l’interop JVM native de Jython. Ce mode est maintenu pour la compatibilité avec les milliers de scripts SikuliX existants et pour les testeurs qui préfèrent l’environnement no-code guidé de l’IDE.

Conséquence directe, démontrée dans le code source d’OculiX (RunTime.java ligne 754) :

public String[] standardExtensions = new String[]{"selenium4sikulix"};

Cette ligne réserve un emplacement dans le ClassLoader pour charger dynamiquement une extension Selenium. Mais le vrai mécanisme va plus loin.

La fonction load() : une curiosité historique pour les utilisateurs de l’IDE

Pour un développeur Java, rien de tout ce qui suit n’est nécessaire : accéder à Selenium, Rest Assured ou n’importe quelle autre lib Maven se fait par simple ajout de dépendance dans le pom.xml et import standard. Aucun mécanisme particulier.

En revanche, pour les utilisateurs de l’IDE OculiX qui écrivent leurs tests en Jython, il faut un moyen de charger un jar externe à chaud dans la JVM de l’IDE en cours d’exécution. OculiX expose pour cela une fonction Python load(), héritée de SikuliX, qui ajoute dynamiquement un jar au classpath. Exemple documenté par Raimund Hocke lui-même :

load("selenium-server-standalone-3.11.0.jar")

Une fois le jar chargé, toutes les classes Java qu’il contient deviennent importables en Jython via la syntaxe Python habituelle :

from org.openqa.selenium.firefox import FirefoxDriver

browser = FirefoxDriver()
browser.get("https://www.google.com")

Ce n’est pas une encapsulation d’OculiX qui traduit les appels Python vers Java. C’est Jython qui, étant un interpréteur Python natif JVM, instancie directement les objets Java comme s’il s’agissait d’objets Python. Le FirefoxDriver créé ici est la même instance que si elle avait été créée dans un programme Java pur.

Ce mécanisme ouvre l’accès à toutes les librairies Java de l’écosystème Maven Central depuis un script OculiX :

Selenium WebDriver pour l’automatisation web
Rest Assured pour les API REST
JDBC drivers pour toute base de données
Apache POI pour Excel, Word, PowerPoint
PDFBox ou iText pour les PDF
Jackson ou Gson pour JSON
Jsoup pour le parsing HTML
SnakeYAML pour YAML
WireMock pour du HTTP mocking
JUnit ou TestNG pour les assertions
SLF4J + Logback pour le logging
n’importe quelle lib JVM publiée sur Maven

Un exemple polyglotte concret

Voici une suite de tests d’intégration qui combine huit stacks techniques différentes dans un seul fichier : automatisation web (Selenium), attente visuelle hors DOM (OculiX), vérification API (Rest Assured), lecture d’un fichier Excel téléchargé (Apache POI), cross-check en base de données (JDBC MySQL), pilotage d’un téléphone Android (OculiX ADBScreen), et capture finale pour le rapport.

Version Java - le mode d’emploi principal, aucun mécanisme spécial

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.By;
import io.restassured.RestAssured;
import io.restassured.response.Response;
import org.apache.poi.ss.usermodel.Workbook;
import org.apache.poi.ss.usermodel.WorkbookFactory;
import org.apache.poi.ss.usermodel.Sheet;
import org.sikuli.script.Screen;
import org.sikuli.script.Pattern;
import org.sikuli.android.ADBScreen;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
import java.io.File;

public class TestIntegrationERP {
    public static void main(String[] args) throws Exception {
        // 1) Automatisation web via Selenium
        WebDriver driver = new FirefoxDriver();
        driver.get("https://erp.monentreprise.fr/login");
        driver.findElement(By.id("user")).sendKeys("admin");
        driver.findElement(By.id("password")).sendKeys("secret");
        driver.findElement(By.cssSelector(".btn-login")).click();

        // 2) Attente visuelle OculiX sur un widget hors DOM
        //    (canvas WebGL d'un graphique financier)
        Screen s = new Screen();
        s.wait("dashboard_chart_rendered.png", 15);

        // 3) Clic visuel sur un point précis du canvas
        s.click(new Pattern("graphique_erp.png").targetOffset(120, -40));

        // 4) Vérification API en parallèle
        Response response = RestAssured.get(
            "https://erp.monentreprise.fr/api/sessions/current");
        assert response.statusCode() == 200;
        assert "admin".equals(response.jsonPath().getString("user"));

        // 5) Export Excel déclenché par le clic
        s.click("bouton_export_excel.png");
        s.wait("telechargement_termine.png", 30);

        Workbook wb = WorkbookFactory.create(new File("Downloads/export.xlsx"));
        Sheet sheet = wb.getSheetAt(0);
        double total = sheet.getRow(25).getCell(4).getNumericCellValue();

        // 6) Cross-check avec la base de données
        Connection conn = DriverManager.getConnection(
            "jdbc:mysql://db.interne:3306/erp", "readonly", "pwd");
        Statement stmt = conn.createStatement();
        ResultSet rs = stmt.executeQuery(
            "SELECT SUM(amount) FROM transactions WHERE date = CURDATE()");
        rs.next();
        double dbTotal = rs.getDouble(1);

        assert Math.abs(total - dbTotal) < 0.01 : "Excel et DB divergent";

        // 7) Validation mobile sur tablette Android via ADB natif
        ADBScreen phone = new ADBScreen();
        phone.click(phone.find("notification_transaction.png"));

        // 8) Screenshot final pour le rapport
        s.capture().save("/tmp/reports", "integration_test_ok.png");

        driver.quit();
        conn.close();
        wb.close();
    }
}

Une seule classe Java. Huit imports depuis quatre écosystèmes Maven distincts (Selenium, Rest Assured, Apache POI, OculiX, JDBC) plus la stdlib Java. Aucune fonction load() magique, aucune glue logic spécifique à OculiX, aucune configuration particulière : le pom.xml déclare les dépendances, le projet compile, le test s’exécute. C’est ce que le mot « plateforme JVM ouverte » signifie concrètement.

Version Jython - la même logique depuis l’IDE OculiX historique

Pour les équipes qui utilisent l’IDE OculiX avec des scripts Jython, le même parcours s’écrit ainsi. La différence structurelle est la fonction load() qui charge les jars externes à chaud, absente de la version Java où Maven gère le classpath nativement :

# Chargement dynamique des libs au début du script
load("selenium-server-standalone.jar")
load("rest-assured-5.3.0.jar")
load("poi-5.2.5.jar")
load("mysql-connector-j-8.0.33.jar")

# Imports Java via Jython
from org.openqa.selenium.firefox import FirefoxDriver
from org.openqa.selenium import By
from io.restassured import RestAssured
from org.apache.poi.ss.usermodel import WorkbookFactory
from java.sql import DriverManager
import java.io.File as JFile

# 1) Automatisation web via Selenium
driver = FirefoxDriver()
driver.get("https://erp.monentreprise.fr/login")
driver.find_element(By.ID, "user").send_keys("admin")
driver.find_element(By.ID, "password").send_keys("secret")
driver.find_element(By.CSS_SELECTOR, ".btn-login").click()

# 2) Attente visuelle OculiX sur un widget que Selenium ne peut pas tester
# (par exemple un canvas de graphique financier rendu en WebGL)
wait("dashboard_chart_rendered.png", 15)

# 3) Clic visuel sur un point précis du canvas
click(Pattern("graphique_erp.png").targetOffset(120, -40))

# 4) Vérification API en parallèle
response = RestAssured.get("https://erp.monentreprise.fr/api/sessions/current")
assert response.statusCode() == 200
assert response.jsonPath().getString("user") == "admin"

# 5) Export Excel déclenché par le clic
click("bouton_export_excel.png")
wait("telechargement_termine.png", 30)

wb = WorkbookFactory.create(JFile("Downloads/export.xlsx"))
sheet = wb.getSheetAt(0)
total = sheet.getRow(25).getCell(4).getNumericCellValue()

# 6) Cross-check avec la base de données directement
conn = DriverManager.getConnection("jdbc:mysql://db.interne:3306/erp", "readonly", "pwd")
stmt = conn.createStatement()
rs = stmt.executeQuery("SELECT SUM(amount) FROM transactions WHERE date = CURDATE()")
rs.next()
db_total = rs.getDouble(1)

assert abs(total - db_total) < 0.01, "Excel et DB divergent"

# 7) Validation mobile sur tablette Android du terrain via ADB natif
from org.sikuli.android import ADBScreen
phone = ADBScreen()
phone.click(phone.find("notification_transaction.png"))

# 8) Screenshot final pour le rapport
capture().save("/tmp/reports", "integration_test_ok.png")

driver.quit()
conn.close()

Les deux versions sont strictement équivalentes : mêmes appels, mêmes objets, même résultat. Le dev Java récupère une classe prête pour JUnit ou TestNG ; l’utilisateur historique de SikuliX garde son environnement Jython familier. Aucun ne perd, aucun n’est pénalisé.

L’intégration Selenium Grid

Puisque Selenium est juste une lib Java qu’on charge dynamiquement, accéder à un Grid Selenium distant se fait via RemoteWebDriver exactement comme dans un projet Java classique :

load("selenium-server-standalone.jar")
from org.openqa.selenium.remote import RemoteWebDriver, DesiredCapabilities
import java.net.URL as URL

caps = DesiredCapabilities.firefox()
caps.setCapability("browserVersion", "latest")
caps.setCapability("platformName", "linux")

driver = RemoteWebDriver(
    URL("http://grid-hub.entreprise.fr:4444/wd/hub"),
    caps
)

# Le Grid alloue un node, un browser s'ouvre à distance
driver.get("https://app.metier.fr")
driver.find_element(By.ID, "login").click()

# Pendant ce temps, OculiX fait du visuel local ou VNC
# selon le screenHolder actif (local Screen ou VNCRefreshRegion)
wait("widget_complexe_non_DOM.png", 10)

Une équipe qui a déjà un Grid opérationnel peut ajouter OculiX à ses scripts sans modifier son infrastructure : le Grid continue d’exécuter les commandes WebDriver standard sur ses nodes, OculiX ajoute par-dessus ses capacités visuelles, OCR et remote VNC/ADB.

Le mode inverse : OculiX comme node Grid

Ce qui n’existe pas encore, c’est le mode où OculiX se présente au Hub comme un executor spécial. Imaginons un scénario où un orchestrateur de test dit : « Je veux lancer cette session sur un node qui sait piloter une caisse retail via VNC ».

Pour ça, il faut qu’OculiX implémente côté serveur le W3C WebDriver Protocol en exposant des capabilities custom :

{
  "capabilities": {
    "platformName": "oculix",
    "oculix:remoteType": "vnc",
    "oculix:targetHost": "caisse-42.magasin-lyon",
    "oculix:ocrEngine": "paddle",
    "oculix:imageRecognition": true
  }
}

Le Grid pourrait alors router les sessions vers un pool de nodes OculiX, chacun connecté à un parc de machines distantes. C’est le ticket roadmap dans le README d’OculiX (ligne 300) :

Appium driver — register OculiX as a Selenium Grid node

Ce chantier représente environ un mois de développement : implémenter l’endpoint HTTP qui parle W3C WebDriver, gérer les sessions, mapper les commandes Grid (click, sendKeys, executeScript) vers les primitives OculiX (click pattern, type, OCR).

La synthèse

OculiX n’est pas un silo qui vit isolé à côté des outils existants. C’est une plateforme JVM ouverte qui, grâce à Jython, peut :

Charger à chaud n’importe quel jar Java de l’écosystème Maven
Utiliser ses classes directement, soit en Java natif via une simple dépendance Maven, soit depuis un script Jython où elles apparaissent comme des objets Python natifs
Combiner dans un même fichier du Selenium WebDriver, des appels API REST, de la requête SQL, du parsing Excel, de la reconnaissance visuelle, de l’OCR, du pilotage VNC distant et du contrôle Android ADB
Se connecter à un Selenium Grid existant comme client (RemoteWebDriver) sans modification d’infrastructure
À terme, s’exposer comme node Grid pour être orchestré par des infrastructures de test distribuées

Cette capacité d’intégration est structurelle — elle vient du choix historique de SikuliX de s’appuyer sur Jython et la JVM, pas d’un effort d’intégration spécifique. C’est la différence entre un outil qui fait « une chose bien » et une plateforme d’automatisation universelle.

6 – Capacités annexes héritées

OculiX hérite d’éléments architecturaux développés sur deux décennies. Au-delà du cœur de l’automatisation visuelle, deux mécanismes méritent d’être mentionnés pour des cas d’usage spécifiques.

Mode serveur HTTP

OculiX intègre un serveur HTTP basé sur Undertow qui expose un endpoint REST permettant à un système externe de déclencher des actions ponctuelles : capturer un screenshot d’une cible distante, vérifier visuellement qu’un écran est dans un état attendu, exécuter un snippet Jython court.

Ce mode n’est pas conçu pour le test automation. Une suite de tests est par nature une séquence d’actions stateful (login, navigation, vérifications enchaînées) qui se prête mieux à un script séquentiel exécuté dans une CI classique avec accès VNC direct à la cible — pas à des appels HTTP indépendants.

Le serveur HTTP s’adresse à des cas d’usage opérationnels et atomiques, sans rapport avec une suite de tests :

Un dashboard de monitoring qui demande périodiquement à OculiX de capturer l’état visuel d’une caisse retail distante
Un webhook qui déclenche une vérification visuelle suite à une alerte métier
Un système de support qui pilote une action one-shot sur une machine utilisateur après l’incident d’un client
Un scheduler qui planifie des contrôles visuels récurrents
Une intégration métier qui veut juste savoir « est-ce que l’écran X est affiché en ce moment sur la cible Y »

Une migration vers HTTPS avec authentification par token et isolation réseau est planifiée pour permettre l’exposition de ce serveur en DMZ entre un système externe (orchestrateur cloud, outil de supervision, plateforme métier) et un parc de cibles isolées.

Mode client distant (NetworkRunner)

Le NetworkRunner permet d’exécuter un script directement depuis une URL :

java -jar oculixide.jar run http://serveur/test_caisse.pyjava -jar oculixide.jar run https://github.com/myorg/scripts/test.sikuli.zip

OculiX télécharge le script (et son bundle d’images si c’est un .sikuli.zip), l’exécute localement et retourne le résultat. Combiné avec le mode serveur, on peut imaginer un orchestrateur central qui distribue des scripts à des nodes OculiX répartis géographiquement.

Cette approche présente toutefois deux contraintes structurelles importantes :

OculiX doit être préinstallé sur la machine cible — le NetworkRunner télécharge le code, mais celui-ci s’exécute localement. Il faut donc Java et OculiX déjà déployés sur chaque cible, ce qui défait l’argument « zéro install sur la cible » du mode VNC.
Les bundles d’images doivent être versionnés et accessibles — pour des suites de tests partagées en équipe, le versionning des .sikuli distants devient rapidement complexe.

Le mode VNC reste préférable pour la grande majorité des cas :

Aucune installation sur la cible (un serveur VNC suffit, souvent déjà présent)
Scripts et images centralisés sur un poste de pilotage unique
Visibilité directe sur ce qui s’exécute — l’écran distant est observable en live
Audit trail naturel — la session VNC peut être enregistrée
Sécurité — seul le poste pilote connaît les credentials du bastion SSH, la cible reste passive

Le NetworkRunner conserve son intérêt pour des scénarios précis : un parc homogène où OculiX est déjà standardisé sur chaque machine, une politique réseau qui interdit le VNC entrant, ou des cas où le test doit s’exécuter sur la machine elle-même (par exemple pour mesurer des performances locales sans biais réseau).

Écosystème

OculiX s’accompagne de composants qui vivent dans leurs propres dépôts et peuvent être utilisés indépendamment :

Apertix — fork OpenCV Java maintenu, utilisé par OculiX pour compiler sur ARM et Apple Silicon
paddleocr-server — microservice Python exposant PaddleOCR derrière une API HTTP, maintenu par oculix-org, packageable sur PyPI

Un système d’extensions via jars tiers, téléchargeables depuis GitHub Releases, est en cours de conception pour la version 4.0. Il permettra d’ajouter des modules de test API REST, de test de bases de données, de HTTP mocking ou de parsing PDF/Excel sans toucher au cœur.

Comment commencer

Le code, la documentation et les binaires sont disponibles sur github.com/oculix-org/Oculix. OculiX propose deux modes d’emploi distincts selon le public visé.

Mode 1 — Dépendance Maven dans votre projet Java (mode principal)

Pour un développeur Java, Kotlin, Scala ou Groovy qui veut intégrer OculiX à un projet existant, la seule chose à faire est d’ajouter la dépendance au pom.xml (ou l’équivalent Gradle) :

<dependency>
  <groupId>io.github.oculix-org</groupId>
  <artifactId>oculixapi</artifactId>
  <version>3.0.1</version>
</dependency>

Les classes du package org.sikuli.script (et les autres packages documentés plus haut) deviennent immédiatement disponibles. Aucun IDE OculiX à installer, aucun serveur à lancer, aucune configuration externe. Le projet compile et tourne comme n’importe quel projet Java standard, dans n’importe quel CI/CD, avec n’importe quel framework de test.

C’est le mode recommandé pour construire une suite de tests d’entreprise pérenne, versionnée sous Git, intégrée à un pipeline Jenkins, GitLab CI, GitHub Actions ou Azure DevOps.

Mode 2 — IDE OculiX standalone (mode historique et no-code)

Pour les testeurs QA qui préfèrent un environnement graphique guidé avec Modern Recorder no-code et scripting Jython, l’IDE OculiX se lance avec un simple java -jar, dans l’un des trois binaires selon votre OS :

java -jar oculixide-3.0.1-windows.jarjava -jar oculixide-3.0.1-macos.jarjava -jar oculixide-3.0.1-linux.jar

Le jar macOS fonctionne aussi bien sur Intel que sur Apple Silicon (M1-M4). Le jar Linux couvre x86 et ARM. Pas de wizard d’installation, pas d’activation en ligne, pas de serveur de licence à joindre. Un jar, une JVM, et c’est parti.

Ce mode est recommandé pour les testeurs non-développeurs, pour la reprise de scripts SikuliX existants, et pour les phases exploratoires où le Modern Recorder permet de capturer rapidement un scénario à convertir plus tard en code pérenne.

Les deux modes partagent exactement la même API et peuvent coexister sans conflit dans une même organisation.

Vingt-trois ans après les premières expérimentations de Rob Miller au MIT, l’automatisation visuelle reste un terrain où un outil libre et gratuit peut couvrir ce qu’aucune solution commerciale ne propose.

Contribuer, tester, comprendre

Si vous voulez filer un coup de main, le projet a trois besoins très concrets aujourd’hui :

Beta testeurs du Modern Recorder sur Windows, macOS et Linux. Trente minutes de session, un retour brut sur ce qui plante ou ce qui frotte, et c’est déjà énorme. L’issue #89 recense ce qu’il reste à valider.
Traducteurs i18n. La base anglaise et française est en place (#88). Si vous parlez allemand, espagnol, italien ou portugais et que ça vous amuse de traduire ~200 clés de propriétés, dites-le en commentaire de l’issue.
Mainteneur Java pour le module ADB / Android. Le code existe et fonctionne sur Android 12+, mais il dort un peu. Quelqu’un qui connaît l’écosystème Android et qui veut un coin de projet OSS bien délimité serait bienvenu.

Le repo est ici : github.com/oculix-org/Oculix. Une issue, une PR, un message — tout est bon à prendre.