CUA : l’infrastructure qui donne un vrai ordinateur à ton agent — et ce qu’elle coûte

TL;DR — CUA en une minute

• Ce que c’est : CUA (trycua, MIT, ~25,8k étoiles, commits quotidiens), la couche d’infrastructure du *computer use* — faire tourner des agents sur de vraies machines macOS, Linux et Windows, isolées. Tagline : *« Give AI agents computers they can use. »*
• Cinq briques : Lume (machines virtuelles locales sur Apple Silicon), Driver (pilotage des apps et navigateurs via CLI, MCP ou SDK), Fleets (bureaux cloud), Bench (évaluation), CUA-S1 (modèles).
• L’idée la plus fine : CUA-S1, de petits modèles « système 1 » qui notent des éléments d’interface au lieu de faire raisonner un gros modèle vision à chaque clic.
• Deux pièges déclarés par le dépôt : un pool cloud peut retenir de la capacité payante après usage ; et la licence MIT ne couvre pas toutes les dépendances (AGPL-3.0 sur un composant optionnel).
• Notre verdict : à tester — la référence du domaine, mais le computer use reste lent, coûteux et fragile.

On a déjà vu comment gouverner un agent qui dispose d’un ordinateur : chaque action autorisée ou refusée avant, auditée après. Voici l’étage en dessous — la machine elle-même.

CUA ne cherche pas à encadrer l’agent, il cherche à lui fournir un vrai poste de travail, isolé, sur le système d’exploitation qu’il faut. Avec 25 800 étoiles, des commits tous les jours et vingt mois d’existence, c’est devenu la référence du domaine. Ce qui mérite qu’on regarde ce qu’il y a vraiment dedans.

Ce que CUA fournit

• Lume — crée et gère des machines virtuelles macOS et Linux locales sur Apple Silicon, en s’appuyant sur le framework de virtualisation d’Apple. C’est la brique la plus remarquable : peu de projets savent donner à un agent une vraie machine macOS isolée.
• Driver — les outils qui inspectent et pilotent les applications natives et les navigateurs, accessibles en ligne de commande, via MCP, ou via des SDK typés. Sur les plateformes qui le permettent, il peut agir sans voler le focus — l’agent travaille pendant que tu fais autre chose.
• Fleets — des bureaux cloud isolés : l’agent réclame un poste dans un pool, l’utilise, le rend.
• Bench — un cadre pour construire des tâches, évaluer un agent et exporter les trajectoires en vue d’un entraînement.
• CUA-S1 — leur propre famille de modèles, poids et jeux de données publiés sur Hugging Face.

Le tout est agnostique : Claude Code, Codex, Cursor — tu amènes ton agent et ton modèle.

L’idée vraiment intéressante : arrêter de faire réfléchir le gros modèle

C’est le point que la démonstration ne montre pas, et c’est le plus important.

Le computer use classique fonctionne ainsi : capture d’écran → gros modèle vision → décision → clic, et on recommence. À chaque geste. C’est ce qui rend l’approche lente et chère : un modèle de raisonnement complet est mobilisé pour décider s’il faut cliquer sur un bouton.

CUA-S1 prend le problème autrement. Ce sont de petits modèles spécialisés, qualifiés de « système 1 » — la pensée rapide et automatique, par opposition au raisonnement lent. Le premier profil publié cible les formulaires : au lieu de générer une réponse mot à mot, il note des éléments d’interface structurés et choisit.

Autrement dit : on réserve le gros modèle aux décisions qui méritent un raisonnement, et on confie les gestes répétitifs à un modèle minuscule qui ne fait que classer. Pour quiconque a regardé la facture d’un agent qui pilote une interface, c’est la bonne direction.

Réserve honnête : le dépôt qualifie lui-même CUA-S1 de publication de recherche précoce, code source uniquement. C’est une piste, pas encore un produit.

Les deux pièges — et ils sont écrits dans le dépôt

Piège nº1 — le cloud qui continue de facturer.

Le projet le dit noir sur blanc : sur les bureaux cloud, un pool peut retenir de la capacité payante après la fin d’un usage, et il faut suivre une procédure de nettoyage. Traduction : un agent qui plante, une boucle mal fermée, et tu paies pour des machines que plus personne n’utilise. À ne jamais lancer sans surveillance de la facture.

Piège nº2 — la licence MIT ne couvre pas tout.

Le cœur est en MIT, et c’est très bien. Mais les dépendances ne le sont pas : OmniParser est en CC-BY-4.0, et un composant optionnel, ultralytics, est en AGPL-3.0. L’AGPL est la licence la plus contaminante qui soit dès qu’on fournit un service en ligne. Si tu édites du logiciel, c’est exactement le genre de détail qui se paie très cher plus tard. Vérifie ce que tu actives.

Le catch honnête, au-delà des deux pièges

• 1 035 tickets ouverts. C’est le signe d’un projet massivement utilisé, pas d’un projet mort — mais aussi d’une friction réelle. Attends-toi à contourner des choses.
• Le computer use reste fragile. L’agent voit une image et clique à des coordonnées. Une interface qui change, une fenêtre qui s’ouvre au mauvais moment, un chargement plus lent que prévu, et il se trompe de cible. La démonstration impressionne ; la fiabilité sur mille exécutions est un autre métier.
• C’est lent. Chaque geste coûte une capture, un aller-retour modèle et un temps de réaction. Là où une API répond en millisecondes, un agent qui clique met des secondes. Par geste.

Pour qui c’est vraiment utile

La règle est simple, et elle évite de perdre des semaines : le computer use se justifie quand il n’y a pas d’API.

• Les logiciels métier fermés : un back-office fournisseur, un extranet sans interface programmable, une application de bureau historique. Là, l’agent qui clique est la seule voie.
• Les tests d’interface et la génération de données : Bench sert exactement à ça — produire des trajectoires, évaluer, entraîner.
• Les tâches multi-applications qui traversent un navigateur, un tableur et un logiciel local dans le même geste.

À l’inverse : si une API existe, utilise l’API. Toujours. Elle sera plus rapide, moins chère, et elle ne cassera pas parce qu’un bouton a bougé de trente pixels.

Notre verdict : à tester

CUA est sérieux, et c’est rare dans ce domaine : licence MIT sur le cœur, virtualisation native sur Apple Silicon, intégration MCP, un banc d’évaluation, et une vraie recherche derrière avec CUA-S1. Vingt mois d’existence, des commits quotidiens, 25 800 étoiles : ce n’est pas un dépôt d’effet d’annonce.

L’idée du « système 1 » — confier les gestes bornés à un petit modèle qui note plutôt qu’à un gros modèle qui raisonne — est la piste la plus prometteuse pour rendre le computer use économiquement viable. À suivre de très près.

Mais avant de s’emballer : surveille la facture cloud (le dépôt prévient que des pools peuvent continuer à coûter), lis les licences des dépendances (l’AGPL rôde), et surtout réserve cette technologie aux interfaces sans API. Dans ce cadre, elle mérite un vrai test.

Points de vigilance

• Facturation résiduelle : un pool cloud peut retenir de la capacité payante après usage — procédure de nettoyage obligatoire.
• Licences en cascade : cœur MIT, mais OmniParser en CC-BY-4.0 et ultralytics optionnel en AGPL-3.0. Critique si tu édites du logiciel.
• Fragilité : l’agent clique sur ce qu’il voit ; une interface qui bouge et il se trompe. Prévoir reprise et supervision.
• Lenteur et coût : chaque geste coûte une capture et un appel modèle. Si une API existe, prends l’API.