Nouveau mot-clé ou API
Une capacité manquante dans la surface d’OculiX : une nouvelle méthode Region, un nouveau matcher, un nouveau geste, un nouveau hook accessibilité. Conçu en public, intégré à l’API publique.
Développement de fonctionnalité sur mesure
OculiX a une roadmap publique. Certaines équipes ont besoin qu’une capacité précise soit rendue disponible plus tôt — un nouveau mot-clé, un nouveau runner, un nouveau connecteur, une amélioration de performance, un portage de plateforme. Le développement sur mesure est l’engagement où vous sponsorisez le temps du mainteneur pour qu’il se concentre sur un livrable défini.
Ce que nous ne faisons pas
Section intitulée « Ce que nous ne faisons pas »Cette page existe en partie pour être clair sur ce que cet engagement n’est pas, parce que le modèle surprend les gens qui viennent des éditeurs commerciaux.
Ce que nous faisons
Section intitulée « Ce que nous faisons »Nouveau runner
Support d’un langage de scripting pas encore couvert (TypeScript via Operix bridge, Kotlin, Groovy en support natif, etc.) ou d’un nouveau mode d’exécution (conteneurisé, serverless, distribué).
Nouveau connecteur
Intégration avec un système nécessitant de la glu Java (un orchestrateur RPA spécifique, un moteur de workflow, un backend OCR particulier, une API cloud de partage d’écran particulière). Atterrit comme module contribué dans le repo OculiX approprié.
Amélioration de performance
Une accélération mesurable sur un goulot précis (matching d’images sur setup multi-moniteurs, warmup JVM, throughput OCR, temps de démarrage en mode headless). Benchmark avant-après ; le benchmark lui-même est publié.
Portage de plateforme
Combinaisons OS/arch pas encore couvertes (Linux ARM, variantes BSD, environnements Windows restreints). Inclut la mise en place d’une couverture matrice CI pour que la plateforme soit supportée durablement, pas juste expédiée une fois.
Backport / stabilisation
Une fonctionnalité sur master que vous avez besoin de backporter sur une branche stable, avec une couverture de tests propre pour que le backport ne régresse pas.
Comment ça marche — design ouvert en 5 étapes
Section intitulée « Comment ça marche — design ouvert en 5 étapes »1. Conversation (gratuite)
Section intitulée « 1. Conversation (gratuite) »Vous décrivez la capacité dont vous avez besoin, le cas d’usage qui la motive, le calendrier qui aurait du sens pour vous. On discute faisabilité, portée, alternatives et interaction avec l’architecture OculiX existante.
Si la fonctionnalité est déjà sur la roadmap et atterrira naturellement dans la prochaine release, on vous le dit — pas d’engagement nécessaire.
2. Issue publique avec proposition de design
Section intitulée « 2. Issue publique avec proposition de design »On ouvre une issue GitHub dans le repo OculiX décrivant la fonctionnalité proposée, l’approche de design et le raisonnement. Votre nom (ou votre organisation, si vous voulez du crédit public) est rattaché comme sponsor. Un sponsoring anonyme est aussi possible si vous préférez.
C’est la partie « en ouvert » : la communauté voit ce qui arrive, peut commenter, peut soulever des préoccupations. Parfois un contributeur propose une approche plus simple à laquelle on n’avait pas pensé. Ça rend la fonctionnalité meilleure.
3. Implémentation sur une branche feature
Section intitulée « 3. Implémentation sur une branche feature »On construit la fonctionnalité sur une branche du repo public. Vous voyez les commits atterrir en temps réel. Si vous voulez, votre équipe peut reviewer les PRs au fil de l’eau (on utilise des draft PRs pour la visibilité pendant le développement).
4. Validation dans votre environnement
Section intitulée « 4. Validation dans votre environnement »Vous testez la fonctionnalité dans votre environnement contre votre cas d’usage réel. Si elle ne se comporte pas comme attendu, on itère. Les critères d’acceptation sont définis en amont dans l’issue, donc « done » est un état documenté, pas un jugement subjectif.
5. Merge sur master, livraison en release
Section intitulée « 5. Merge sur master, livraison en release »Une fois validée, la fonctionnalité atterrit sur master. Elle part dans la prochaine release OculiX (ou plus tôt comme jar hot-fix, voir Support production). Votre organisation obtient :
- Crédit dans les release notes
- Co-Authored-By sur le merge commit (si vous avez des contributeurs qui ont participé)
- Mention publique sur la page Adoption (avec votre accord)
Modèle de tarification
Section intitulée « Modèle de tarification »Le développement sur mesure est tarifé par blocs de temps focalisés :
- Discovery + design — forfait pour les livrables Phase 1 + Phase 2 (issue de design publique + critères d’acceptation). Typiquement 1-2 semaines.
- Build + ship — forfait ou taux horaire selon la prévisibilité de la portée. Discuté en toute transparence dans la lettre d’engagement.
On ne vend pas des « heures » de mainteneur de façon abstraite. On vend une fonctionnalité avec un état de « done » défini, avec des jalons liés à cet état.
Exemples (anonymisés)
Section intitulée « Exemples (anonymisés) »Une organisation healthcare a sponsorisé l'intégration PaddleOCR
Un provider healthcare avait besoin d’OCR précis sur des documents en langues asiatiques. Tesseract ne suffisait pas. Ils ont sponsorisé l’intégration du serveur HTTP PaddleOCR comme backend opt-in. Expédié comme repo compagnon paddleocr-server plus un toggle de configuration OculiX. Maintenant disponible pour tous.
Une banque a sponsorisé le support async des devices ADB
Une banque faisant tourner des tests UI mobile à l’échelle avait besoin d’opérations ADB asynchrones pour paralléliser sa suite. Ils ont sponsorisé l’API async ADBDevice. Expédié dans OculiX 3.0.2 comme ADBDevice.swipeAsync() et compagnie. Leur suite est passée de 90 minutes à 18.
Une agence gouvernementale a sponsorisé le journal d'audit MCP
Une agence gouvernementale exigeait un logging infalsifiable de chaque action automatisée. Ils ont sponsorisé le module serveur MCP avec journal d’audit JSONL signé Ed25519 et chaîné SHA-256. Livré comme module séparé. Maintenant utilisé par plusieurs adopteurs en secteur régulé.
Un industriel a sponsorisé le matching multi-moniteurs
Une chaîne de production avec des stations opérateur 6 moniteurs avait besoin d’un pattern matching fiable sur tout le bureau virtuel. Ils ont sponsorisé la réécriture de la normalisation des coordonnées multi-moniteurs. Expédié dans OculiX 3.0.0 comme Screen.all() retournant une région de recherche unifiée.
Questions fréquentes
Section intitulée « Questions fréquentes »Peut-on avoir une fonctionnalité privée ?
Section intitulée « Peut-on avoir une fonctionnalité privée ? »Non. Chaque fonctionnalité expédiée par OculiX est MIT, publique, disponible pour tous. Si vous avez besoin d’une capacité privée qui ne peut vraiment pas être publique (parce qu’elle embarque de l’IP propriétaire), c’est en dehors de ce que couvrent les engagements OculiX — il vous faudrait maintenir un fork vous-même.
Pourquoi ce modèle ?
Section intitulée « Pourquoi ce modèle ? »Parce que la valeur d’OculiX, c’est la confiance que rien n’est caché. Si on expédiait des fonctionnalités privées pour des clients payants, la version publique deviendrait une variante « lite », ce qui est l’inverse de la philosophie MIT-OSS. La garantie « la version gratuite est la même version » est ce qui fait que 91+ organisations adoptent OculiX.
Et si on ne veut pas que notre nom soit public ?
Section intitulée « Et si on ne veut pas que notre nom soit public ? »Le sponsoring peut être anonyme. L’issue de design référencera « sponsorisé par un utilisateur OculiX » sans vous nommer. Le Co-Authored-By du merge commit peut être omis. La mention sur la page Adoption est opt-in.
Quelle garantie qu’on a que la fonctionnalité sera mergée ?
Section intitulée « Quelle garantie qu’on a que la fonctionnalité sera mergée ? »Les critères d’acceptation sont définis en amont dans l’issue publique. Tant que la fonctionnalité atteint ces critères, elle merge. Le risque de « non mergée » est atténué par la Phase 1 — on ne prend pas l’engagement s’il y a une raison architecturale qui empêche la fonctionnalité d’atterrir proprement. La pré-discussion est précisément ce qui attrape ça.
Et la propriété intellectuelle ?
Section intitulée « Et la propriété intellectuelle ? »La fonctionnalité est MIT. Votre sponsoring ne vous donne pas la propriété de l’IP — vous ne pouvez pas la revendre comme du code propriétaire. Vous POUVEZ référencer votre sponsoring publiquement (releases, marketing, conférences). La plupart des sponsors trouvent l’échange équitable.
Et si la communauté pousse sur le design ?
Section intitulée « Et si la communauté pousse sur le design ? »On écoute. L’étape « design ouvert » est précisément là pour faire émerger les objections tôt. Si la communauté propose une meilleure approche, on l’adopte (avec votre avis). S’ils s’opposent à l’existence même de la fonctionnalité, on a une conversation honnête sur la suite. Jusqu’à présent, aucun engagement n’a été bloqué par une opposition communautaire — mais l’option existe.
Combien de temps tourne un engagement typique ?
Section intitulée « Combien de temps tourne un engagement typique ? »Discovery + design : 1-2 semaines. Build + ship : typiquement 2-8 semaines selon la complexité. Total : 3-10 semaines pour la plupart des fonctionnalités.
Un petit mot-clé : 3-4 semaines total. Un nouveau runner ou un gros travail de perf : 8-10 semaines. Refonte architecturale : au cas par cas.
Plusieurs organisations peuvent-elles co-sponsoriser ?
Section intitulée « Plusieurs organisations peuvent-elles co-sponsoriser ? »Oui, et on l’encourage pour les fonctionnalités plus grosses. Plusieurs sponsors partagent le coût, tous obtiennent le crédit, la fonctionnalité atterrit toujours MIT en une fois. On coordonne le recueil des besoins entre sponsors via l’issue de design.
Prenez-vous des engagements pour des fonctionnalités que vous auriez construites de toute façon ?
Section intitulée « Prenez-vous des engagements pour des fonctionnalités que vous auriez construites de toute façon ? »D’habitude non — ce serait sponsoriser quelque chose qui arrive déjà. Mais si votre calendrier est significativement plus serré que le nôtre et qu’il vous faut l’avoir plus tôt, l’engagement c’est le décalage temporel, pas la fonctionnalité elle-même. On est transparent là-dessus côté tarif.
Nous contacter
Section intitulée « Nous contacter » Décrivez la fonctionnalité dont vous avez besoin Quelques lignes sur la capacité que vous voulez, le cas d'usage qui la motive et un calendrier approximatif. On revient avec un avis de faisabilité sous 48 h.
Parcourez la roadmap publique d'abord Votre fonctionnalité arrive peut-être déjà. Regardez les issues publiques avec le label 'roadmap'.
🦎