OSWorld : mesurer les agents multimodaux sur un vrai bureau, pas sur une capture d'écran

Ce que le banc d'essai cherche à capturer

La plupart des évaluations d'agents s'arrêtent à une question de texte ou à une action isolée. OSWorld vise autre chose : des tâches ouvertes, exécutées dans un environnement de bureau réel, où l'agent doit regarder l'écran, cliquer, taper, ouvrir des applications et atteindre un état final vérifiable. Le dépôt décrit un ensemble d'exemples d'évaluation rangés dans `evaluation_examples`, avec un visualiseur de données accessible depuis la page du projet. Le public visé est donc celui qui travaille sur les agents multimodaux, les modèles de langage appliqués au contrôle d'interface, ou l'automatisation de processus robotiques. La promesse n'est pas de fournir un agent performant, mais de fournir le terrain sur lequel on peut mesurer si un agent l'est.

Une VM pilotée, un contrôleur qui observe

L'architecture repose sur une séparation nette entre l'environnement et l'agent. Le paquet Python s'appelle `desktop-env` et s'installe seul avec `pip install desktop-env` si l'on ne veut pas des tâches du benchmark. La classe `DesktopEnv` est le point d'entrée : on l'initialise en précisant un fournisseur et un type de système, par exemple `provider_name` valant `docker` et `os_type` valant `Ubuntu` ou `Windows`. Le fournisseur se charge de faire tourner la machine virtuelle, et le contrôleur expose à l'agent ce que la documentation appelle l'état de l'écran ainsi que les actions possibles. L'évaluation ne juge pas la trajectoire mais l'état final du système, ce qui autorise plusieurs chemins pour réussir une même tâche. Le dépôt a été refactorisé en juin 2024 pour séparer l'intégration VMware du reste, ce qui a permis d'ajouter VirtualBox, AWS et Azure par la suite. Cette décomposition est le vrai apport technique : elle transforme un script lié à un hyperviseur en une interface où le fournisseur est un paramètre.

Installer selon la machine que vous avez

Le chemin dépend entièrement de l'endroit où vous exécutez le code. Sur un poste non virtualisé, la documentation demande de cloner le dépôt, d'installer `requirements.txt` avec Python 3.10 ou plus, puis d'installer VMware Workstation Pro (ou VMware Fusion sur Apple Silicon) et de vérifier que `vmrun` répond avec `vmrun -T ws list`. Le script de configuration télécharge ensuite les machines virtuelles nécessaires. Sur un serveur, la voie recommandée est Docker avec KVM : `egrep -c '(vmx|svm)' /proc/cpuinfo` doit renvoyer une valeur supérieure à zéro, et macOS est explicitement exclu de cette voie. Sur Modal, la procédure est différente : `pip install 'modal>=1.5.0'`, `modal setup`, puis `python -m desktop_env.providers.modal.setup --os Ubuntu` pour préparer l'image, et enfin `python quickstart.py --provider_name modal --headless true`. Trois chemins, trois niveaux d'effort, et la documentation ne les présente pas comme interchangeables.

Ce que la version du benchmark change

Un point mérite attention avant toute comparaison. La note du 28 juillet 2025 annonce OSWorld-Verified, présentée comme une mise à jour qui corrige des problèmes signalés par la communauté, ajoute un support AWS permettant selon le rapport de ramener le temps d'évaluation sous une heure grâce à la parallélisation, et rend les signaux du benchmark plus efficaces. La même note demande de comparer ses résultats aux nouveaux résultats publiés sur le site officiel lorsque l'on utilise la dernière version. Autrement dit, un score obtenu sur une version antérieure n'est pas directement comparable à un score obtenu sur OSWorld-Verified. Les dernières versions listées dans le dépôt sont v0.1.16 du 26 juin 2024 et v0.1.0 du 11 avril 2024, alors que la note de juillet 2025 décrit un état plus récent du projet : la chronologie des releases et celle des annonces ne coïncident pas, et il faut s'en tenir à ce que le dépôt indique au moment où l'on travaille.

Les cas où OSWorld n'est pas le bon outil

Le coût d'entrée est le premier obstacle. Il faut une plateforme de virtualisation fonctionnelle, et sur macOS la voie KVM est fermée, ce qui renvoie vers VMware. Sur un serveur partagé, les conteneurs Docker résiduels après une interruption peuvent dégrader les performances, et la documentation donne la commande de nettoyage : `docker stop $(docker ps -q) && docker rm $(docker ps -a -q)`. Ce détail n'est pas anodin : il indique que l'environnement n'est pas isolé par défaut et qu'une exécution interrompue laisse des traces. Deuxième limite : si votre objectif est de tester une automatisation ciblée sur une application précise, un banc d'essai généraliste ajoute de la variabilité sans rien apporter. Troisième limite : les tâches ouvertes rendent l'évaluation plus réaliste mais aussi plus difficile à interpréter, puisque plusieurs chemins mènent à l'état final attendu. Enfin, VirtualBox est proposé comme solution de repli, mais la documentation précise que la parallélisation et macOS sur puces Apple y sont mal prises en charge. C'est un aveu utile : le repli existe, il n'est pas équivalent.

Comparer avec une approche sans machine virtuelle

L'alternative la plus évidente est un banc d'essai qui simule l'interface plutôt que de l'exécuter. On y gagne en reproductibilité et en vitesse, puisque tout tourne dans le même processus et que l'état est inspectable directement. On y perd ce qui fait l'intérêt d'OSWorld : les délais de rendu, les fenêtres qui se chevauchent, les applications dont l'état réel ne correspond pas à ce que le modèle croit voir. Un environnement simulé valide une politique d'action ; OSWorld valide la capacité à agir dans un système qui ne coopère pas. Le choix dépend donc de la question posée. Si vous cherchez à savoir si un agent sait cliquer au bon endroit dans un environnement déterministe, la simulation suffit et coûte beaucoup moins cher. Si vous cherchez à savoir s'il tient face à un bureau réel, il faut une VM, et OSWorld est construit pour cela.

Licence et coût de suivi

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec obligation de conserver les mentions de copyright et le texte de la licence, et avec une clause de brevets. Rien dans le matériel fourni n'indique de restriction sur les données d'évaluation elles-mêmes, mais les tâches et les images de machines virtuelles proviennent de sources distinctes du code, et il appartient à chaque équipe de vérifier les conditions applicables à ces artefacts avant un usage en production. Sur la maintenance, le dépôt a reçu des mises à jour jusqu'au 30 août 2026 et les notes de version montrent un rythme irrégulier : deux releases en 2024, puis des annonces fonctionnelles en 2025. Le suivi implique de retélécharger les images et les fichiers de pré-initialisation, disponibles sur un lien de cache mentionné dans le README, et de réexécuter les évaluations à chaque changement de version du benchmark. Ce coût de réexécution est structurel : il fait partie de la méthode, pas de l'installation.

Conclusion éditoriale

OSWorld convient aux équipes qui entraînent ou comparent des agents capables d'enchaîner des actions GUI et qui disposent déjà d'une machine ou d'un serveur pour héberger des VM. Il ne convient pas à qui cherche un environnement léger pour prototyper une automatisation sur un poste de travail : la mise en place passe par vmrun, par KVM ou par Modal, et la version du benchmark change les scores publiés. Avant de comparer vos chiffres à ceux du site officiel, vérifiez si vous exécutez OSWorld-Verified ou une version antérieure, et lancez d'abord `vmrun -T ws list` ou `egrep -c '(vmx|svm)' /proc/cpuinfo` selon votre plateforme.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. xlang-ai/OSWorld on GitHub