En avril 2026, AskUI a publié une comparaison qui présente le choix en automatisation visuelle comme s’il était déjà tranché. Les outils déterministes basés sur l’image y sont décrits comme un paradigme dépassé — utile pour la nostalgie, limité par la résolution d’écran, bloqué sur l’exécution headless, désarmé sur le mobile, condamné à être remplacé par des agents pilotés par LLM qui « comprennent » l’interface au lieu de comparer des pixels.
J’ai lu l’article d’AskUI attentivement. Il est bien écrit, et son SEO va voyager. Il est aussi, sur la plupart de ses affirmations structurantes concernant OculiX, factuellement faux — de plusieurs releases stables d’écart.
L’intention de ce billet n’est pas d’attaquer un concurrent. L’intention est de poser par écrit, calmement, ce qu’OculiX 3.0.4 fait réellement en 2026, pour qu’un acheteur lisant les deux côtes à côte puisse décider sur des faits observables plutôt que sur l’extrait soigneusement cadré qu’AskUI a choisi de publier.
Avant d’entrer dans la correction point par point, laisser-moi nommer les deux paradigmes équitablement, parce qu’ils n’ont pas la même forme et ne servent pas la même contrainte.
Automatisation visuelle déterministe
Un script écrit en code. Un pattern stocké comme une image. Un matcher qui décide, par comparaison pixel par pixel, si le pattern est à l’écran. Même entrée, même sortie, à chaque exécution. Aucun modèle, aucun token, aucun aller-retour cloud dans le chemin critique. Auditable de bout en bout.
Automatisation agentique pilotée par LLM
Une instruction en langage naturel. Un modèle multimodal qui interprète l’écran et décide où cliquer. Même entrée, sortie plausiblement similaire, jamais reproductible au bit près. Le comportement change quand la version du modèle change. Facturé au token par aller-retour. L’auditabilité reste un sujet de recherche.
Ces deux paradigmes ne sont pas interchangeables dans une pratique QA professionnelle. Le paradigme déterministe produit des artefacts reproductibles à la demande : la régression de production, les pistes d’audit de qualité conformité, les périmètres en air-gap, tout test qui doit produire le même résultat aujourd’hui, demain et dans trois ans sur une autre machine. Le paradigme agentique, par construction, ne le peut pas — et une équipe QA qui optimise pour la confiance, l’audit et la reproductibilité ne peut rationnellement le retenir comme moteur principal. C’est la thèse que j’ai défendue publiquement sur le non-déterminisme des LLM appliqués à l’automatisation : vendre une exécution autonome non reproductible comme produit de test est une faute professionnelle, pas un compromis acceptable.
Le billet d’AskUI prétend pourtant que l’agentique est l’héritier inévitable du déterministe, en étayant ce cadrage par des affirmations sur le côté déterministe qui sont soit dépassées de plusieurs versions mineures, soit vraies d’un outil mais étendues à un autre par amalgame, soit simplement incorrectes. C’est la combinaison des deux mouvements — un cadrage stratégique faux et un constat technique faux — qui rend la réponse nécessaire.
Je vais les reprendre une par une.
AskUI décrit OculiX comme « un build de développement appelé OculiX 3.0.1 […] également disponible avec support VNC, contrôle Android ADB, intégration PaddleOCR et langages de scripting additionnels ».
Ce qui sort réellement en juin 2026 :
| Élément | Réalité |
|---|---|
| Version stable courante | OculiX 3.0.4, publiée et téléchargée par près d’une centaine d’organisations en production |
| Prochaine majeure | OculiX 4.0, scopée, en développement actif, ciblée mi-2026 |
| Déploiements | Fortune 500, entreprises APAC, secteur défense — observables via la télémétrie publique Scarf |
| Moteur OCR | Tesseract embarqué statiquement via Legerix, autosuffisant, sans aucune dépendance PaddleOCR dans la stable |
Qualifier OculiX de « build de développement » dans une comparaison écrite pour un public 2026 n’est pas une petite inexactitude. Cela indique au lecteur que l’alternative qu’il évalue est instable, alors que c’est l’inverse. Le choix du numéro de version « 3.0.1 » par AskUI semble renvoyer à une release d’un trimestre antérieur ; leur comparaison a été publiée des mois plus tard, après que plusieurs releases stables aient été livrées.
AskUI affirme que l’exécution headless n’est « pas supportée » et qu’« un écran réel et déverrouillé est requis ».
C’est vrai de SikuliX lancé localement, sur le poste face au développeur. Ce n’est pas vrai d’OculiX dans la configuration que la majorité des équipes de production déploie.
OculiX livre une architecture VNC distante, documentée et supportée, où :
C’est le déploiement de production utilisé par la majorité des déploiements OculiX à l’échelle. Ce n’est pas headless au sens strict de « aucun framebuffer rendu jamais » — ce serait physiquement incompatible avec le matching de pixels comme paradigme. C’est headless au sens qui intéresse l’acheteur : le test ne bloque pas l’écran de l’opérateur, le test tourne sans surveillance en CI, le test ne nécessite pas qu’un humain soit connecté physiquement devant la machine de test.
AskUI étend une limitation réelle de l’exécution locale de SikuliX à toute l’automatisation basée sur l’image, ce qui est trompeur. OculiX a dépassé cette limite plusieurs années avant que leur comparaison soit rédigée.
C’est la même confusion architecturale que dans l’affirmation 2. Dans une session OculiX locale — comme dans une session AutoIt, AutoHotKey ou pyautogui locale — la souris et le clavier appartiennent au script qui tourne. C’est intrinsèque au pilotage d’une UI desktop, indépendamment du vendeur.
Dans un déploiement OculiX en session VNC, le test tourne dans un framebuffer séparé sur une VM séparée. La souris et le clavier du développeur ne sont pas disputés. C’est précisément ce que les équipes de production exécutant de la régression visuelle à l’échelle demandent, et c’est précisément ce qu’OculiX fournit. AskUI présente cela comme une limite catégorielle de l’automatisation basée sur l’image ; en pratique, la limite a été levée il y a des années par l’architecture de déploiement de l’outil.
OculiX 3.0.4 livre un mécanisme de cache de locator persistant, embarqué à l’intérieur des fichiers PNG utilisés comme patterns. Les coordonnées du dernier match réussi de chaque pattern sont stockées dans un chunk auxiliaire privé du PNG (oPLx), préservé par tous les outils d’image standards, survivant au git clone, et lu par OculiX au prochain démarrage à froid.
L’impact mesuré sur un ordinateur portable i3 vieux de cinq ans, en configuration strict cold-start mimant un environnement CI, est une accélération de ×6.5 sur l’opération find : de 502 ms en baseline à 77 ms en médiane. Sur du matériel moderne, les valeurs absolues rétrécissent mais l’accélération relative reste de ×6 à ×8.
Tout cela est documenté en détail dans mon billet de benchmark de mai 2026, avec la méthodologie, le harness, et les chiffres bruts.
L’affirmation d’AskUI selon laquelle OculiX n’a « aucune capacité de cache d’exécution » a été publiée après la mise en production de la feature et après la publication du benchmark. Elle reflète soit un processus de recherche qui n’a pas regardé le changelog, soit une omission délibérée d’un contre-exemple gênant.
OculiX 3.0.4 livre un support Android de première classe, exposé via ADB, avec sélection de device par numéro de série, réveil/déverrouillage idempotent par KEYCODE_WAKEUP, et fermes multi-devices parallèles. C’est le cas depuis plusieurs releases mineures.
L’interface est documentée, le code est dans le dépôt public, et les cas de test qui l’exercent sont dans la suite de tests. Un simple git log --grep android sur le dépôt public fait remonter les commits récents introduisant le sélecteur de device par série et le découplage du réveil.
La comparaison d’AskUI en 2026 affirme qu’OculiX n’a « aucun support mobile » — c’est soit dépassé de plusieurs mois, soit la lecture délibérée d’une vieille branche unique. Dans les deux cas, c’est faux concernant la release stable qu’un acheteur téléchargerait réellement aujourd’hui.
Cette affirmation est techniquement vraie de la forme naïve du template matching — la forme pratiquée par les outils basés image en 2010. Elle n’est pas vraie de l’implémentation Finder.java d’OculiX en 2026, qui cascade cinq modes de matching :
| Mode | Stratégie | Tolérance |
|---|---|---|
| 1 | Match template standard | Aucune — chemin rapide pour le match exact |
| 2 | Rescale DPI-aware | Différences de résolution et de scaling entre capture et cible |
| 3 | Match avec flou gaussien | Antialiasing, variations subtiles de couleur |
| 4 | Match convert en niveaux de gris | Dérive du thème de couleur |
| 5 | Brute force multi-échelle | Scaling de 0.5× à 2×, dernier recours |
Un pattern capturé sur un écran 1920×1080 à 100 % de scaling et matché sur un écran 2560×1440 à 125 % de scaling est exactement le cas pour lequel le mode 2 a été conçu. Le matcher ne « casse » pas ; il change de stratégie et trouve le pattern. C’est dans le code base depuis des années.
Présenter la limitation de 2010 comme si elle définissait toujours l’état de l’outil en 2026 est une figure de débat classique : prendre la pire version de la position contre laquelle on argumente, et la traiter comme si elle était la seule. L’article d’AskUI utilise exactement cette manœuvre.
Ce n’est pas dit littéralement par AskUI, mais cela imprègne la structure de leur billet : la colonne déterministe est présentée comme une liste de limitations, la colonne agentique comme une liste de capacités.
Le cadrage honnête est l’inverse, selon la contrainte de l’acheteur :
Ce que vous donne le déterministe
Reproductibilité au bit près. Même script, même entrée, même sortie, aujourd’hui et dans trois ans. Coût par exécution nul. Fonctionnement en air-gap, sans dépendance cloud sur le chemin critique. Échec auditable : quand un test échoue, la trace dit exactement pourquoi. Survit aux changements de version de modèle qui perturbent les suites pilotées par LLM tous les trimestres.
Ce que vous donne l'agentique
Une rédaction initiale plus rapide, au prix d’artefacts qui ne sont pas reproductibles. Une tolérance à la dérive d’UI, au prix de passes silencieuses quand le modèle interprète l’écran de travers. Des interfaces en langage naturel, au prix de personne capable de déboguer le test quand il échoue. Une facturation à l’exécution, indéfiniment. Aucun de ces compromis n’est défendable pour du QA professionnel.
Une équipe QA qui protège un terminal de paiement sous audit fiscal a besoin de la colonne de gauche. Une équipe growth qui smoke-teste une landing page marketing peut probablement se permettre la colonne de droite. Prétendre que l’une ou l’autre catégorie est la réponse universelle, c’est vendre à l’acheteur un paradigme plutôt que l’aider à résoudre un problème.
Au-delà des affirmations techniques, les deux paradigmes diffèrent dans leur forme économique, et la différence compte davantage que ce que la comparaison reconnaît.
| Dimension | OculiX 3.0.4 | Alternative pilotée LLM |
|---|---|---|
| Conditions d’usage commercial | MIT, illimitées, code public | Non-commerciales sur le palier gratuit, plans payants requis pour la production |
| Transparence tarifaire | Gratuit, aucun plan d’upgrade | Plans non divulgués publiquement, passage obligatoire par les sales |
| Coût chemin critique par test | Zéro — CPU local | Inférence facturée au token par aller-retour |
| Dépendance cloud | Aucune dans le déploiement par défaut | Agent OS cloud, hub d’inférence hébergé |
| Adéquation air-gap | Native | Nécessite un plan enterprise self-hosted, contrat sur mesure |
| Self-hosted à l’échelle | Mode par défaut | Tier enterprise uniquement |
| Auditabilité des runs | Déterministe au byte près | Sujette à la dérive de modèle et de prompt |
Pour un acheteur qui exécute cent mille tests par jour, le coût d’inférence par token du modèle agentique n’est pas une erreur d’arrondi. C’est une dépense opérationnelle récurrente qui croît avec l’usage. L’alternative déterministe n’a aucune dépense de ce type : le script tourne sur le runner que l’acheteur allait provisionner de toute façon, et le matcher utilise des cycles CPU qui seraient autrement inactifs.
Pour un acheteur dans un secteur régulé — banque, défense, santé, industrie sous contrôle qualité traçable — les exigences d’air-gap et d’audit ne sont pas négociables. Un outil qui requiert un hub d’inférence cloud ne franchit même pas la phase d’évaluation. Un outil qui tourne entièrement on-premise sous conditions MIT open source franchit cette porte par construction.
La comparaison d’AskUI survole les deux, présentant le pricing comme « commence à zéro » et l’air-gap comme « disponible en enterprise ». Un acheteur qui ne lit que la surface marketing pourrait conclure que la différence est petite. Un acheteur qui regarde les contrats et l’architecture de déploiement conclura autrement.
Le paradigme agentique est régulièrement défendu sur quatre cas d’usage. Je ne les considère pas comme des justifications recevables pour le QA professionnel — je les liste pour qu’on voie pourquoi.
Dans aucun de ces quatre cas la facturation à l’inférence cloud, la dépendance à une version de modèle qui changera, ou la perte de reproductibilité ne deviennent acceptables pour un référentiel de tests qui doit tenir des années. AskUI est un produit réel et bien exécuté dans son espace ; l’espace lui-même n’est simplement pas celui du QA professionnel, indépendamment du fournisseur.
Le point qui suit ne porte pas spécifiquement sur AskUI. Il s’applique à n’importe quel éditeur — quelle que soit la marque, quel que soit le discours marketing — qui propose un modèle d’inférence facturé au token sur une plateforme cloud-only pour une activité dont la nature est à fort volume, répétée et contrainte budgétairement. La QA, c’est précisément cette activité-là.
Permettez-moi de poser le décalage structurel.
La QA est, par sa raison d’être, un exercice de volume :
Multipliez par le nombre d’équipes, par le nombre de produits, par le nombre d’environnements, par le nombre de replays nécessaires pour analyser les tests flaky. Une pratique QA sérieuse dans une organisation moyenne à grande exécute des centaines de milliers de tests par jour. Ce n’est pas une échelle pathologique. C’est le plancher normal.
Superposez maintenant un modèle tarifaire à l’inférence sur ce volume.
| Scénario concret | Inférences par jour | Trajectoire de coût au tarif inférence typique |
|---|---|---|
| Petite équipe, smoke quotidien | ~5 000 | Gérable en année 1, scale linéairement |
| Produit de taille moyenne, PR + nuit + canary | ~50 000 | Devient une ligne budgétaire visible |
| Pratique QA enterprise multi-produits | ~500 000 | Devient une conversation de board |
| Replay qualité conformité pour reconstruction d’audit | ~1 000 000 | Devient un deal-breaker |
Le QA lead qui choisit un outil au tarif à l’inférence hérite d’un problème structurel avec deux pressions opposées :
Pour contrôler le coût
L’équipe est poussée à tester moins — sauter la canary, abandonner la nuit, restreindre le périmètre de régression. Le coût est contenu au détriment de la couverture.
Pour préserver la qualité
L’équipe est poussée à dépenser plus — garder la couverture intacte, accepter la facture linéaire, escalader vers les achats quand la ligne dépasse le seuil. La qualité est préservée au détriment du budget.
Les deux pressions convergent vers un plafond budgétaire qui arrive plus vite que la maturation de la pratique.
Aucun frais par exécution
Une suite de régression qui tourne dix fois aujourd’hui et cent fois demain consomme dix et cent fois les minutes de runner que l’organisation payait déjà. Le vendeur n’est pas impliqué dans le coût marginal.
Coût marginal ≈ secondes de CPU
Chaque exécution supplémentaire coûte le prix d’une seconde de CPU supplémentaire sur un runner déjà provisionné. La pratique QA peut mûrir sans renégocier le moindre contrat.
C’est la raison structurelle pour laquelle la plupart des secteurs régulés — banque, défense, santé, industrie sous contrôle qualité traçable — n’ont jamais adopté un moteur d’automatisation cloud à l’inférence comme moteur principal, et ne le feront pas. Ce n’est pas une question de confiance ou de maturité. C’est une question d’arithmétique.
Les arguments abstraits sur les modèles tarifaires sont plus faciles à écarter que des chiffres concrets. Permettez-moi de poser des volumes réels sur la table.
Avant les chiffres, ce que le service éditeur couvre réellement. Le moteur OculiX est gratuit ; le service éditeur est un engagement optionnel à forfait, surposé pour les acheteurs qui veulent un canal privé, des engagements de délai de réponse, des interlocuteurs nommés, ou un statut vendor-of-record. Trois paliers, trois prix forfaitaires qui ne scalent pas avec le volume QA de l’acheteur :
| Palier | Ce qui est couvert | Cible typique |
|---|---|---|
| Support Petite Équipe (~12 – 15 k€/an) | Canal e-mail privé, réponse < 5 jours ouvrés, priorisation des bugs, accès roadmap | Équipe unique exécutant OculiX en production, désireuse d’un canal privé sans bureaucratie |
| Service éditeur Premium (~35 – 70 k€/an) | Tout Petite Équipe + hotline sur créneaux convenus, réponse < 1 jour ouvré, revue trimestrielle, influence directe sur la roadmap | Équipe produit de taille moyenne où l’automatisation est sur le chemin critique, multiples interlocuteurs |
| Service éditeur Enterprise (~90 – 180 k€/an, remise volume au-dessus de 150 k€) | Tout Premium + ingénieur référent nommé, réponse < 4 heures ouvrées, SLA contractuel, astreinte sur fenêtres critiques de release, statut vendor-of-record (auditable) | Pratique QA enterprise avec exposition réglementaire, périmètre multi-produits ou multi-entités |
Ce que chaque niveau exclut explicitement : développements de features sur mesure (engagement séparé, facturé à la feature), travail en régie sans fin (l’engagement est au forfait — l’éditeur porte le risque de réalisation, pas l’acheteur), et couverture 24/7 en dehors des fenêtres critiques nommées. L’acheteur sait toujours ce qu’il paie ; l’éditeur sait toujours ce sur quoi il s’engage.
Le point structurel : à n’importe quel palier, le prix est forfaitaire pour l’année, indépendamment du nombre de tests exécutés. Une équipe qui double son volume de test l’année prochaine paie la même chose. Une équipe qui quadruple paie la même chose. La ligne budgétaire est prédictible pour la revue budgétaire, exactement ce que les alternatives facturées à l’inférence ne peuvent pas offrir.
Cela étant posé, les trois scénarios d’acheteur.
| Outil / modèle | Coût année 1 | Cumul 3 ans | Comportement de coût |
|---|---|---|---|
| mabl (plan Team + minutes d’exécution supplémentaires) | ~12 000 – 15 000 € | ~36 000 – 45 000 € | Linéaire avec les minutes d’exécution |
| testRigor (tier Pro, ~5 000 steps/mois) | ~6 000 – 10 000 € | ~18 000 – 30 000 € | Linéaire avec les steps de test |
| Applitools Eyes / Autonomous (Growth) | ~6 000 – 25 000 € | ~18 000 – 75 000 € | Linéaire avec les Test Units |
| AskUI (abonnement + Hub à tokens) | Non communiqué — contact commercial | Même forme — linéaire avec le volume | Linéaire avec les appels d’inférence |
| OculiX OSS | 0 € | 0 € | Constant |
| OculiX OSS + Support Petite Équipe (optionnel) | ~12 000 – 15 000 € | ~36 000 – 45 000 € | Constant — engagement éditeur forfaitaire |
À cette échelle, la ligne la moins chère est OculiX OSS à zéro euro, point final. Pour les acheteurs qui veulent un canal privé, des engagements de délai, une priorisation des bugs, et un accès roadmap, le pack Support Petite Équipe d’OculiX se trouve dans la même bande de prix que les offres concurrentes les moins chères — et reste forfaitaire à mesure que le volume QA croît, au lieu de scaler avec les exécutions. Le moteur OSS seul suffit à beaucoup d’équipes ; le support éditeur est un bonus, pas une obligation.
| Outil / modèle | Coût année 1 | Cumul 3 ans | Comportement de coût |
|---|---|---|---|
| mabl (Enterprise, sur devis) | ~40 000 – 80 000 € | ~120 000 – 240 000 € | Devis sur mesure, linéaire avec l’usage |
| testRigor (Enterprise, steps quasi illimités) | ~60 000 – 100 000 € | ~180 000 – 300 000 € | Devis enterprise sur mesure |
| Applitools Enterprise | ~50 000 – 100 000 € | ~150 000 – 300 000 € | Devis enterprise sur mesure |
| AskUI (abonnement + inférence lourde) | Non communiqué — contact commercial | Même forme — linéaire avec le volume | Linéaire avec les appels d’inférence |
| OculiX OSS | 0 € | 0 € | Constant |
| OculiX OSS + Service éditeur Premium (optionnel) | ~35 000 – 70 000 € | ~105 000 – 210 000 € | Constant — engagement éditeur forfaitaire |
À 1 000 exécutions par jour, les outils concurrents commencent à ressembler à des dépenses opérationnelles avec leur propre ligne dans la revue budgétaire. OculiX OSS coûte toujours zéro. Le service éditeur Premium d’OculiX commence à 35 000 € par an — sous le point d’entrée de chaque palier enterprise concurrent dans cette tranche — avec hotline, réponse sous un jour ouvré, revue trimestrielle, et influence directe sur la roadmap. Le prix reste forfaitaire quel que soit le volume QA atteint. Doubler la suite l’an prochain laisse la ligne OculiX au même chiffre ; les alternatives concurrentes scalent linéairement avec l’usage.
Sur un horizon de trois ans, l’écart n’est plus marginal. OculiX Premium s’accumule à ~105 000 – 210 000 € sur trois ans. Mabl Enterprise s’accumule à ~120 000 – 240 000 €. testRigor et Applitools s’accumulent à ~150 000 – 300 000 €. AskUI ne publie pas de prix, je ne fabriquerai donc pas de cumul — ce qui est observable de leur modèle, c’est qu’il scale linéairement avec le volume d’inférence, ce qui à 250 000 exécutions par an aggrave mécaniquement l’écart. Même à la borne haute de la fourchette OculiX Premium, le total reste sous l’entrée de testRigor et Applitools et au bas de mabl Enterprise. À cinq ans et à dix ans, l’écart s’élargit encore — parce que la ligne OculiX est forfaitaire et que les lignes concurrentes ne le sont pas.
| Outil / modèle | Coût année 1 | Cumul 3 ans | Comportement de coût |
|---|---|---|---|
| mabl / testRigor / Applitools (Enterprise+, sur devis) | ~200 000 – 500 000 € | ~600 000 – 1 500 000 € | Devis sur mesure, linéaire avec l’usage |
| AskUI (Hub d’inférence complet à 2.5 M exécutions) | Non communiqué — contact commercial | Même forme — linéaire avec le volume | Linéaire avec les appels d’inférence |
| OculiX OSS | 0 € | 0 € | Constant |
| OculiX OSS + Service éditeur Enterprise + remise volume (optionnel) | ~180 000 – 250 000 € | ~540 000 – 750 000 € | Constant avec remise volume |
À 10 000 exécutions par jour, l’écart n’est plus une comparaison — c’est une déclaration catégorielle sur quel paradigme passe à l’échelle économiquement. OculiX OSS coûte zéro. OculiX avec service éditeur complet plus remise volume reste bien en-dessous de ce qu’un acheteur paierait pour l’alternative à l’inférence, avant même de compter le lock-in cloud.
Il est tentant, en lisant les tableaux ci-dessus, de voir le service éditeur Premium ou Enterprise d’OculiX comme une simple ligne de vendor lock-in supplémentaire. Ce n’est pas le cas, et la différence structurelle compte.
Le moteur OSS tourne sans lui
OculiX est MIT, les binaires sont publics, la documentation est sur le site, le canal communautaire est ouvert. Une équipe peut adopter OculiX, le faire tourner en production pendant dix ans, et ne jamais payer un euro à l’éditeur. Ce n’est pas théorique — beaucoup parmi la centaine d’organisations déployées font exactement cela.
Le service éditeur est un engagement forfaitaire
Quand une équipe choisit d’engager l’éditeur, elle paie un prix annuel forfaitaire pour SLA, ingénieur nommé, statut vendor-of-record, influence roadmap et support de migration. Le prix ne scale pas avec le nombre de tests qu’elle exécute. Elle peut quadrupler son volume QA l’an prochain sans renégocier.
La sortie est réelle
À la fin d’un engagement, l’équipe garde tout son code base, ses patterns, ses pipelines CI, ses automatisations. Il n’y a aucun format propriétaire à extraire, aucun hub cloud à quitter, aucune facture token qui survit au contrat. Le moteur OSS tourne pareil le jour d’après le contrat que le jour d’avant.
Le modèle est Red Hat, pas SaaS
Red Hat ne facture pas par cycle CPU sur Linux. Confluent ne facture pas par message Kafka. Sonatype ne facture pas par artefact Nexus résolu. OculiX ne facture pas par exécution de test. L’éditeur vend l’engagement et le support autour d’un moteur gratuit — le modèle OSS-plus-services éprouvé.
Un acheteur qui ne lit que le tableau prix par outil pourrait cadrer le choix comme « gratuit vs payant ». Ce cadrage manque le point. Le choix est : payer à l’usage indéfiniment, ou ne rien payer et engager l’éditeur seulement si et quand l’acheteur valorise le faire. La décision est réversible. Le plafond de coût est connaissable. La sortie est à un git pull d’écart.
Le cadrage honnête pour un acheteur évaluant l’automatisation visuelle en 2026 ressemble à ceci :
Ces quatre questions sont observables. L’acheteur peut y répondre sans dépendre d’un narratif marketing fournisseur. Elles n’exigent pas de choisir entre « passé » et « futur » ; elles exigent de reconnaître que la QA est de l’engineering, et que l’engineering ne négocie pas la reproductibilité.
OculiX 3.0.4 est, en 2026, le runtime d’automatisation visuelle déterministe le plus complet disponible sous conditions MIT open source. Il tourne sur Windows, macOS y compris Apple Silicon, et Linux. Il supporte Android. Il tourne en sessions VNC pour exécution distante et parallèle. Il persiste son cache de locator dans un format portable qui survit au git clone et aux runners CI. Il est utilisé en production par près de cent organisations à travers les secteurs régulés. Le code est sur GitHub. Les conditions open source sont irrévocables. La prochaine release est scopée et publique.
Si la contrainte de l’acheteur est la reproductibilité, l’audit, l’air-gap, ou le coût par exécution nul, OculiX est la réponse. Si la contrainte de l’acheteur est de l’exploration assistée avec validation humaine systématique, ce qu’il cherche est un assistant — pas un moteur de test. Le confondre avec une automatisation QA est un abus de langage que le marché finira par corriger. Quoi qu’il en soit, le choix doit être fait sur les faits concernant l’état actuel de chaque option — pas sur une photographie 2024 d’un outil étendue en article 2026 sur un autre.
Je publie les données que je peux vérifier. Je lie à l’article d’AskUI qui a provoqué celui-ci pour que tout lecteur puisse vérifier les deux côtés par lui-même. Le dépôt est ouvert. La méthodologie du benchmark est publique. L’architecture est documentée. Il n’y a aucune couche cachée dont l’accès se négocie.
C’est la différence que font réellement les conditions open source MIT.
La comparaison honnête
Des classements qui concluent qu’OculiX est le mauvais outil pour un cas d’usage donné, appuyés par des affirmations techniques exactes. Une orientation de l’acheteur vers un concurrent quand le concurrent convient mieux. Le marché mûrit quand les comparaisons sont factuelles — et OculiX n’a rien à craindre d’une comparaison honnête.
La représentation fausse systématique
Des numéros de version faussés de plusieurs releases stables. Des features livrées décrites comme absentes. Des limitations d’un outil non lié attribuées à OculiX. Des architectures de déploiement ignorées alors qu’elles sont publiquement documentées. C’est une catégorie différente et elle est traitée comme telle.
Recours juridiques préservés
Les mainteneurs préservent tous les recours juridiques disponibles dans nos juridictions : représentation fallacieuse, publicité comparative trompeuse, diffamation lorsque le seuil est atteint, et les droits moraux attachés à la paternité du code.
Le dialogue est la première démarche
Ces recours ne sont pas exercés en première réponse. Le chemin privilégié est le dialogue, la correction et le droit de réponse — ce billet est lui-même la correction publique offerte amiablement. L’escalade arrive seulement quand le pattern persiste et que la correction proposée est ignorée.
Universel, pas ciblé
Ceci n’est pas un avertissement adressé à un concurrent spécifique. C’est une position qui s’applique à n’importe qui, aujourd’hui ou demain, qui choisit de concurrencer OculiX par la fabrication plutôt que par un argument technique et économique honnête.
MIT protège l'utilisateur, pas la représentation fausse
Les conditions MIT accordent un droit illimité d’utiliser, modifier et redistribuer le code. Elles ne dépouillent pas les mainteneurs de leur personnalité juridique, de leurs intérêts réputationnels, ni des protections que les droits français et européen étendent aux acteurs économiques honnêtes.
Dépôt : github.com/oculix-org/Oculix
Benchmark référencé : Stocker la mémoire spatiale dans un PNG (mai 2026)
Article auquel ce billet répond : AskUI vs SikuliX (avril 2026)
