Oups ! Une erreur s'est produite lors de l'envoi du formulaire.
Votre agent de codage peut écrire du code. Mais peut-il déposer une note de frais ? Ouvrir une application de bureau ? Remplir un formulaire qui se trouve derrière un mur de connexion ?
C'est la question qui anime la toute nouvelle catégorie d'outils d'IA : les agents d'utilisation d'ordinateur. Le Codex d'OpenAI inclut désormais une fonctionnalité d'utilisation de l'ordinateur qui permet à l'agent de voir votre écran et d'interagir avec les applications via des captures d'écran et des clics de souris. Le Simulang de Simular adopte une approche fondamentalement différente : il lit l'arbre d'accessibilité du système d'exploitation et écrit des scripts déterministes qui se rejouent sans LLM dans la boucle.
J'ai testé les deux sur le même ensemble de tâches d'automatisation de bureau. Voici ce que j'ai trouvé — et quand choisir l'un plutôt que l'autre.
Codex est l'agent IA d'OpenAI plateforme. Lancé à l'origine comme un modèle de génération de code en 2021, Codex a évolué pour devenir un agent complet capable d'écrire du code, d'exécuter des commandes de terminal, de naviguer sur le web et — depuis sa dernière mise à jour — de contrôler les applications de bureau grâce à une fonctionnalité d'utilisation de l'ordinateur.
La capacité d'utilisation de l'ordinateur fonctionne en prenant des captures d'écran de l'écran de l'utilisateur, en les envoyant à un modèle de vision et en renvoyant des actions de souris/clavier. L'agent voit ce que vous voyez — une grille de pixels — et décide où cliquer, quoi taper et quand faire défiler.
Codex fonctionne par défaut dans un bac à sable cloud. La fonctionnalité d'utilisation de l'ordinateur étend cela aux ordinateurs de bureau locaux via une architecture de plugins.
Simulang est un langage de script pour automatiser les navigateurs, les applications natives et les flux de travail au niveau du système d'exploitation. Il est open source, s'installe avec
npm install -g @simular-ai/simulanget produit des scripts TypeScript qui interagissent avec les applications via les API d'accessibilité du système d'exploitation. Simulang est produit et soutenu par Simular.
Au lieu de regarder des captures d'écran, Simulang lit l'arbre d'accessibilité — la même interface structurée qu'utilisent les lecteurs d'écran comme VoiceOver et JAWS. Chaque bouton, champ de texte, élément de menu et étiquette est exposé comme un élément nommé et adressable par référence. Le script interagit par référence, et non par coordonnées de pixels.
Simulang est conçu être le format de sortie des agents de codage. Claude Code, Cursor, ou tout outil de codage basé sur un LLM peut écrire un script Simulang une seule fois, et ce script se rejoue de manière déterministe — aucun LLM n'est requis à l'exécution.
C'est la principale différence architecturale, et cela affecte tout ce qui en découle.
Utilisation de Codex sur ordinateur prend une capture d'écran (généralement 1920x1080 pixels), l'envoie à un modèle de vision, et demande : « Où est le bouton Envoyer ? » Le modèle renvoie des coordonnées. Codex déplace la souris vers ces coordonnées et clique.
Cette approche présente trois problèmes :
Simulang lit l'arbre d'accessibilité et attribue un ID de référence stable à chaque élément. Le script indique tree.activate("ref_42") — et non « cliquer au pixel (847, 312) ». Si la fenêtre se déplace, la référence est toujours valide. Si la mise à l'échelle du système d'exploitation change, la référence est toujours valide. Si une boîte de dialogue apparaît, Simulang lit le nouvel arbre et trouve l'élément par son identité sémantique.
Temps de réponse par action : millisecondes. Un flux de travail en 10 étapes s'achève en moins d'une seconde.
Cette différence détermine à la fois le coût et la fiabilité.
Utilisation de l'ordinateur Codex nécessite un appel LLM pour chaque interaction. Ouvrir un menu : appel LLM. Cliquer sur un bouton : appel LLM. Saisir du texte dans un champ : appel LLM. Chaque appel coûte des jetons, ajoute de la latence et introduit un risque de mauvaise interprétation. Exécutez le même flux de travail 100 fois, et vous payez pour 100 x N appels LLM (où N est le nombre d'étapes).
Simulang utilise le LLM une seule fois — au moment de la création du script. L'agent de codage (Claude Code, Cursor, etc.) écrit le script Simulang, et à partir de ce moment, le script s'exécute de manière déterministe. Exécutez-le 100 fois, et vous ne payez pour aucun appel LLM supplémentaire.
La différence de coût n'est pas marginale. Pour un flux de travail quotidien en 20 étapes, exécuté 5 jours par semaine :
Les deux outils peuvent interagir avec n'importe quelle application qui apparaît à l'écran — mais le mécanisme diffère.
Codex est agnostique aux applications par conception : si c'est visible sous forme de pixels, Codex peut essayer d'interagir avec. C'est vraiment utile pour les applications qui n'ont pas d'API, pas de support d'accessibilité et pas de points d'accroche d'automatisation. Les logiciels d'entreprise hérités, les canevas rendus sur mesure et les sessions de bureau à distance sont tous des cibles potentielles.
Simulang gère les navigateurs nativement (via des API d'accessibilité de type Playwright) et s'étend à toute application native qui expose des données d'accessibilité — ce qui inclut pratiquement toutes les applications standard macOS, Windows et Linux. Pour les rares applications qui n'exposent pas de données d'accessibilité, Simulang se rabat sur l'ancrage visuel : il prend une capture d'écran et utilise un modèle de vision pour localiser l'élément cible.
La différence pratique : Simulang utilise le chemin rapide et déterministe (arbre d'accessibilité) pour 95 % des interactions et le chemin lent et probabiliste (vision) pour les 5 % restants. Codex utilise le chemin lent et probabiliste pour 100 % des interactions.
Codex fonctionne par défaut dans une VM cloud. Votre code, vos fichiers et vos identifiants sont téléchargés vers l'infrastructure d'OpenAI. Le plugin Computer Use étend Codex aux ordinateurs de bureau locaux, mais l'architecture de base est axée sur le cloud.
Simulang s'exécute entièrement sur votre machine locale. Les scripts s'exécutent sur votre bureau réel — vos sessions de navigateur, vos applications connectées, votre système de fichiers. Rien n'est téléchargé. Rien ne quitte votre machine à moins que le script n'envoie explicitement des données quelque part.
Pour les entreprises soumises à des exigences de conformité (SOC 2, HIPAA, réglementations financières), l'exécution locale est souvent non négociable. Pour les développeurs individuels qui souhaitent automatiser des flux de travail impliquant des sessions authentifiées (e-mail, services bancaires, outils internes), l'exécution locale signifie aucun partage d'identifiants.
L'équité compte. Voici où Codex présente de réels avantages :
Pour la plupart des développeurs qui créent des flux de travail d'automatisation de production, Simulang est le choix le plus pratique : écrivez le script une fois, exécutez-le indéfiniment, ne payez rien par exécution. Pour les tâches de bureau ad hoc où vous voulez pointer une IA sur votre écran et dire "fais ceci", Codex Computer Use est plus rapide à prendre en main.
Les deux outils ne sont pas mutuellement exclusifs. Vous pouvez utiliser Codex (ou Claude Code, ou Cursor) pour écrire des scripts Simulang — obtenant le meilleur des deux mondes : intelligence LLM au moment de la création, exécution déterministe au moment de l'exécution.