Arrêtez d'apprendre aux agents à regarder l'écran : CLI-Anything donne une ligne de commande à chaque logiciel

Il y a une forme très particulière de désespoir qui vous saisit quand vous regardez un agent IA essayer d'utiliser un logiciel de bureau. Il prend une capture d'écran, devine où se trouve le menu, clique, rate, reprend une capture. Vingt secondes plus tard, il a déplacé un curseur de deux pixels et n'a rien appris.

CLI-Anything, du Data Intelligence Lab de l'University of Hong Kong, soutient que toute l'approche est fausse. N'apprenez pas à l'agent à voir l'écran. Donnez une ligne de commande au logiciel, et laissez l'agent taper.

Le pitch tient en une ligne : rendre tout logiciel agent-native. Le mécanisme est moins glamour et plus intéressant — pointez une commande vers n'importe quelle application dont vous avez les sources, et un pipeline en sept étapes génère pour elle un wrapper CLI structuré, avec tests, documentation et un paquet qui s'installe avec pip.

Les sept étapes

Le pipeline tourne à l'intérieur d'un agent de codage, invoqué par /cli-anything <source path or repo>. Analyser : parcourir les sources et faire correspondre les opérations GUI à des appels d'API. Concevoir : décider des groupes de commandes, du modèle d'état, des formats de sortie. Implémenter : construire un CLI basé sur Click, avec un REPL, une sortie JSON et undo/redo. Planifier les tests : écrire un plan de test dans TEST.md. Écrire les tests : implémenter la suite. Documenter : consigner les résultats dans le même fichier. Publier : créer un setup.py et installer la commande dans votre PATH.

Il existe aussi une étape 6.5 qui génère un SKILL.md, pour que le CLI produit soit repérable par un agent comme une skill, plutôt que d'être quelque chose qu'un humain doit câbler à la main. Et une commande /cli-anything:refine qui fait une analyse des manques et étend la couverture par petites touches.

Le nommage est rigide exprès : les commandes vivent sous l'espace de noms cli_anything.<software>, les paquets s'appellent cli-anything-<software>. Ce sont les conventions ennuyeuses qui rendent l'outillage composable, et ce projet pense manifestement déjà à un monde où il en existerait des centaines.

De vrais backends, pas des réimplémentations jouets

Le détail qui sépare ce projet d'un projet de week-end : les wrappers pilotent le vrai logiciel. LibreOffice produit un vrai PDF. Blender rend une vraie scène 3D. GIMP fait à l'image ce que GIMP fait aux images. L'alternative — réimplémenter un sous-ensemble du comportement de l'application en Python — accouche de quelque chose qui a l'air de marcher jusqu'au jour où il vous faut la fonctionnalité que la réimplémentation a sautée.

Le coût, c'est qu'il faut avoir les applications installées. Le bénéfice, c'est que la sortie est indiscernable de ce qu'un opérateur humain aurait produit, puisque c'est le même moteur qui l'a produite.

Chaque commande émet du JSON quand on le lui demande, et c'est toute la différence entre un CLI qu'un agent peut parser et un CLI qu'un agent doit déchiffrer en plissant les yeux. Il y a un REPL avec état pour le travail interactif et de simples sous-commandes pour les scripts, plus un état de projet persistant et undo/redo.

Ce que ça couvre

Le périmètre est volontairement large, et il se lit comme la liste des logiciels que les gens essaient d'automatiser sans y arriver : GIMP, Blender et Kdenlive pour la création ; LibreOffice pour les documents bureautiques ; Godot et s&box pour la 3D et le jeu ; QGIS et FreeCAD pour les sciences et l'ingénierie ; ComfyUI et Ollama côté IA ; LLDB, RenderDoc et Nsight pour le débogage.

ComfyUI mérite une pause si vous travaillez avec des images. ComfyUI a déjà une API, mais c'est une API de graphe — des nœuds, des câbles, et un blob JSON dont le schéma dépend des nœuds personnalisés que vous avez installés. Un wrapper CLI qui expose des commandes au niveau de l'intention, avec un modèle d'état défini et une sortie JSON, c'est exactement ce qu'il faut à un agent pour faire tourner un pipeline d'images sans rétro-ingénierie du fichier de workflow de quelqu'un d'autre.

L'argument des tests

Le dépôt annonce environ 2 461 tests : 1 732 unitaires, 579 de bout en bout et 19 Node.js, avec un taux de réussite revendiqué de 100 %. La couche E2E tourne contre le vrai backend, et c'est la seule sorte d'E2E qui compte ici. Si LibreOffice cesse de produire un PDF, le test échoue, et vous l'apprenez avant que votre agent n'ait généré quarante fichiers cassés.

Prenez le « 100 % » comme un instantané, pas comme une garantie. Les suites de tests générées ont la mauvaise habitude d'inscrire dans le marbre les hypothèses du générateur. Mais la structure en quatre couches — unitaire, E2E natif, E2E sur vrai backend, et sous-processus CLI — a la bonne forme.

Les limites, dites honnêtement

Le README les énumère, ce qui est bon signe.

Il dépend de modèles de frontière. Claude Opus 4.6 ou Sonnet 4.6, GPT-5.4, cette classe-là. Un modèle plus faible produit des CLI incomplets ou faux, qu'il faut réparer à la main pendant des heures — autrement dit, l'utilité de l'outil est liée à un abonnement que vous n'avez peut-être pas.

Il dépend du code source. Le pipeline analyse les sources ; si vous n'avez qu'un binaire compilé, la qualité et la couverture s'effondrent. Ce qui exclut discrètement la plupart des logiciels commerciaux, c'est-à-dire l'essentiel de ce que les gens veulent réellement automatiser.

Une seule exécution couvre rarement tout. Attendez-vous à lancer /refine plusieurs fois avant que le harnais soit au niveau production. Certains CLI exigent que l'application amont soit installée. La maturité varie selon la plateforme — Goose, OpenCode, Codex, Hermes et Reasonix sont marqués expérimentaux, et les utilisateurs de Windows rencontreront des problèmes de compatibilité avec bash et cygpath.

La question de maintenance que personne ne veut poser

Un wrapper généré, c'est un engagement. Dès que vous adoptez cli-anything-libreoffice, vous avez ajouté une couche entre votre agent et l'application, et cette couche doit continuer de fonctionner quand LibreOffice change son modèle de document ou que Blender renomme un opérateur.

En pratique, cela veut dire trois choses. Gardez le harnais généré dans votre propre dépôt plutôt que de dépendre de celui de quelqu'un d'autre, pour pouvoir le corriger. Relancez le pipeline quand vous mettez à jour l'application sous-jacente, et diffez le résultat. Et traitez TEST.md comme le contrat — les tests sont la seule raison pour laquelle vous remarquerez une casse avant que votre agent ne produise quarante fichiers malformés.

L'économie tient parce que la régénération est bon marché. C'est là l'idée vraiment neuve : le wrapper n'a pas besoin d'être parfait pour toujours, parce que ce qui l'a produit peut le produire à nouveau. Les SDK traditionnels coûtent cher à maintenir parce que des humains les écrivent. Ici, ce n'est pas le cas.

Le pari CLI-Hub

Il existe un gestionnaire de paquets, cli-anything-hub, pour parcourir et installer les wrappers construits par la communauté. C'est la partie du projet avec le plus fort potentiel et le risque le plus évident. Un hub de CLI générés, c'est un hub de code qui tourne avec vos permissions et touche à vos fichiers.

Qu'il devienne un écosystème utile ou un épisode de chaîne d'approvisionnement dépend entièrement de si le projet considère la revue comme faisant partie de la publication. Pour l'instant, la réponse est « en partie » : les tests sont générés, la doc est générée, et la revue est ce que la communauté en fait.

Pourquoi cela compte au-delà du dépôt

Depuis deux ans, le computer use est la démo préférée de l'industrie et son produit le moins aimé. Les démos marchent parce que quelqu'un a soigneusement scripté une tâche. Les produits calent parce que le contrôle au pixel près est fragile d'une manière qui ne disparaît jamais tout à fait.

CLI-Anything propose une autre répartition du travail : au lieu de rendre les agents meilleurs à être des humains, rendre les logiciels meilleurs à être des machines. Toute application dotée d'une arborescence de sources devient candidate à une interface générée, et cette interface est testable d'une façon qu'une boucle de captures d'écran ne sera jamais.

Le compromis est réel. Un CLI généré ne vaut pas mieux que le modèle qui l'a écrit, et il faudra bien que quelqu'un s'occupe du wrapper quand l'application amont change. Mais la direction est la bonne. Un agent qui tape cli-anything-blender render --scene scene.blend --out frame.png et obtient une sortie déterministe fait quelque chose de fondamentalement plus utile qu'un agent qui clique dans un viewport en espérant que ça passe.